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ABSTRACT 


The  SPLICE  systsa  is  designed  to  integrate  a  variety  of 
current  and  projects!  NA7SU?  processing  and  telecommun ica- 
tions  applications.  The  operation  of  the  more  than  twenty 
new  applications  systems  currently  under  development  will 
increase  the  Navy's  dependence  on  automated  support,  and 
will  require  that  the  risk  of  operating  the  SPLICE  data 
processing  environaent  be  evaluated  and  managed  at  an  accep- 
table level.  This  thesis  identifies  the  requirements  for 
implementing  a  Risk  Management  Program,  provides  a  formal 
model  for  the  quantification  aid  management  of  risk,  and 
examines  contemporary  technical  and  managerial  countermea- 
sures  which  could  bs  effective  in  reducing  the  operational 
risk  of  SPLICE. 
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I.  BACKGaOJIiD 

A.   INTRODUCTION  TO  RISK  MANAGEMENT 

Computers  have  besoms  an  integral  part  of  the  business 
and  government  world  by  perforning  many  of  the  operations 
and  applications  that,  in  the  past,  were  either  done  manu- 
ally or  not  at  all.  In  addition  to  spending  vast  sums  of 
money  to  acguire  and  operate  computer  hardware,  Navy  activi- 

—  J  ~  cr  V-=v^  Tiir^a  ^  c:  v  ~  ~  ^  Ti  aril  sni^   :   "a^-A'  crr>-c'(-v^T-o 

development,  communication  links  for  remote  terminals  and 
networks,  site  construction  and  daily  operating  expenses, 
and  the  administrative  overhead  of  a  data  processing  depart- 
ment staff.  More  importantly,  the  proliferation  of 
computers  has  affected  the  day-to-day  operations  at  a  number 
of  Navy  activities.  Many  activities  depend  so  heavily  on 
their  computers  that  if  the  computers  ceased  operation, 
either  the  activities  would  fail  to  accomplish  their  mission 
or  they  would  suffer  a  severe  degradation  in  their  mission 
effectiveness. 

The  introduction  of  automation  has  resulted  in  a 
substantial  increase  in  the  risk  an  activity  faces.  For 
example,  the  centralization  of  data  and  services  is  often 
associated  with  a  remote  access  capability.  This  added 
capability  permits  interrogation  and  alteration  of  data 
files  with  little  or  no  check  on  the  authenticity  of  the 
source.  Additionally,  there  is  often  a  reduction  in  the 
accessibility  of  visual  records  accompanying  the  shift  to 
automated  support.  In  a  manual  system,  sales  ledgers, 
payment  books,  and  invoices  are  maintained  by  various 
internal  departments  to  manags  and  monitor  an  activity's 
business.         In    a   computerized    system,    these    same    records    are 
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retained  on  magnetic  storage  neclia  and  are  updated  automati- 
cally by  a  software  program.  rhe  accuracy  and  authenticity 
of  these  records  has  become  tha  joint  responsibility  of  the 
data  processing  department  and  the  user,  which  often  results 
in  uncertainty  about  the  responsibility  for  data  integrity. 
The  question  is  who  is  responsible  for  the  data  --  the  user 
who  originates  the  input  and  uses  the  result,  or  the  data 
processing  department,  which  has  day-to-day  responsibility 
for  the  automated  processing.  These  new  risks  have  gener- 
ated an  obligation  of  management  to  protect  this  significant 
investment  and  to  provide  for  continuity  of  operations 
should  a  catastrophe  or   accident  occur.   [Ref.  1:  pp.  1-8] 

Protection  can  be  accomplished  by  designing,  developing 
and  implementing  coun  termeasur  es .  These  countermeasures, 
which  can  be  either  commerically  procured  or  developed 
in-house  by  the  activity,  must  prevent,  minimize,  or  assist 
the  data  processing  environment  to  recover  from  any  acci- 
dental or  intentional  i ^authorized  modification, 
destruction,  disclosure,  or  denial  of  service.  This  process 
of  safeguarding  data  processing  assets  is  called  automatic 
data  processing  (ADP)  security. 

Perfect  security  is  generally  regarded  as  unattainable. 
Therefore,  the  objective  of  a  good  ADP  security  program  is 
to  reduce,  for  a  reasonable  cose,  the  probability  of  loss  to 
an  acceptable  level  aid  to  provide  adequate  recovery  in  case 
of  loss  [Ref.  2:  p.  2].  A  good  program  can  only  be  achieved 
by  having  t cp  management  ultimately  responsible  for  the  ADP 
security  program  and  by  applying  quantitative  techniques  to 
determine  how  much  protection  is  needed  to  reduce  the  risk 
of  operating  to  an  acceptable  level. 

There  are  many  approaches  to  help  top  management  deter- 
mine the  appropriate  ADP  security  policy.  The  most  endorsed 
approach  uses  risk  itanagement  as  the  tool  to  develop  and 
implement  that  policy.   Risk  management  is  a  methodology  for 
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analyzing  an  environment  and  ietsrmining  ths  optimal  sat  of 
courtermea suzes  needei  to  provide  sufficient  protection  for 
■chat  environment. 

The  General  Accounting  Office  (GAO)  reports  that  "... 
risk  management  is  an  element  of  managerial  science  that  is 
concerned  with  the  ilentif icatioa,  measurement,  control,  and 
minimization  of  impact  of  uncertain  events  upon  organiza- 
tions that  depend  np:i  automated  operations"  [Ref.  2:  p. 35]. 
Robert  H.  Courtney,  Jr.,  a  pioneer  of  risk  analysis  tech- 
niques, says: 


Most 
risk 
hcoe 
tain 
gene 
iana 
succ 
tain 
reco 
to  d 


man 

-the 

or  w 


ageme 
char. 

ant  t 
and , 
acce 


rally 
gemen 
ess  1 1 

gmze 
eal  w 


or 

and 

th 


nt   a 

ce  th 

hem  fc 

in 

pted 

Most 
not  i 
o   as 
uant 
em  i 


ti 


eci 

a  t 

0  . 

1  ee 
as 
f  r 

a 

s  urn 
ify 
a  a 


sions  involve   the   assumoti 
things  may  not  turn  out  the 

Decisions  made  in  spite  of 
d,    in  recognition   of   the 

essential   to  dynamic   succ 


-  h  a 


equentiy,         nowever, 

the   willingness      to    accent 

e      risk.       But      in      the    abili 

the    elements    of   that      risk 

fully    objective    way.       [Ref. 


on 

of 

way 

we 

unce 

r-  — 

m   a 

—  o 

essf 

ul 

ey 

tc 

u  n  c  e 

r— 

ty 

to 

so 

as 

3: 

P* 

B.       REQUIREMENTS    FOR    RISK    MANAGEMENT 

1  •      £§.il.§El.if    2i2*££S®S.£   2t   Def ens.e   and    DsRartment   of    the 
Navy_ 

The  first  fed 
security  and  risk  anal 
major  concerns  precipi 
personal  information  a 
potential  risk  posed  b 
sophisticated  informat 
responsibilities  to 
about  individuals  col 
to  that  which  is  leg 
maintained        in      a        m 


eral  regulation  that  addressed  data 
ysis  was  the  Privacy  Act  of  1974.  Two 
tated    this    law:  the    total    amount   of 

aintained  by  Federal  agencies,  ana  the 
y  the  increasing  use  of  computers  and 
ion  systems.  The  Act  defines  specific 
guarantee  that  personal  information 
lected  by  Federal  agencies  is  limited 
ally  authorized  and  necessary  and  is 
anner        which      precludes         unwarranted 
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intrusions    upon    individual    privity.  Ths    Act   requires    each 

agency  to  establish  appropriate  administrative,  technical, 
and  physical  safeguards  to  ensare  the  integrity  and  confi- 
dentiality of  personal  information  and  to  protect  against 
any  anticipated  threats  or  hazards  which  could  result  in 
harm,  embarrassment,  i nconveniei oe,  or  unfairness.  [Ref.  4: 
p.    133] 

When  the  Act  became  law  on  31  December  197U,  virtu- 
ally every  agency  in  the  Federal  government  was  impacted. 
Because  of  its  implementation  responsibility,  the  Office  of 
Mar.aaement  and  Budget  (OMB)  was  particularly  affected.  0M3 
responded  to  the  Act  by  issuing  0M5  Circular  No.  A- 108, 
"Responsibilities  for  the  Maintenance  of  Records  About 
Individuals  by  Federal  Agendas,"  dated  1  July  1975. 
Specific   taskings   associated    with    this    ciroular    are: 

•  The  National  Bureai  of  Standards  (NBS)  is  responsible  for 
issuing  standards  and  guidelines  on  computer  and  data 
security . 

•  The  General  Servioes  Administration  (GSAi  is  responsible 
for  revising  coapiter  and  telecommunications  procurement 
policies  to  ensure  compliance  with  applicable  provisions 
cf    the    Act. 

•  The  (White  House)  Office  of  Telecommunications  Policy  is 
responsible  for  reviewing  Federal  agency  policy  on  inter- 
connection and  operational  control  of  networks  and 
communication   security    devices.       [Ref.    4:    p.     19] 

The  Privacy  Act  of  1974  was  the  first  in  a  series  of 
events  during  the  197D«s  that  focused  national  level  atten- 
tion on  the  value  and  vulnerability  of  Federal  data 
processing.  Following  the  Act,  in  the  spring  of  1976,  three 
GAO  reports  were  published  that  brought  congressional  atten- 
tion to  this  growing  ooncern  and  increased  awareness  of  the 
potential   risks    facing    the      Federal    ADP    community.         Shortly 


13 


•thereafter,  Senator  Abraham  Ribicoff  directed  the  Committee 
on  Government  Operations  to  oonduct  a  preliminary  inquiry 
into  the  problems  of  computer  security.  The  Committee 
subsequently  issued  two  studies  addressing  the  subject.  The 
first  report  reviewed  soma  of  the  major  technological  issues 
and  problems  identified  by  SAO  and  provided  an  extensive 
collection  of  articles  written  by  experts  in  the  field  of 
computer  security  [Ref.  5 ]•  The  follow-up  report  recom- 
mended that  OMB  direct  Federal  agencies  to  put  into  effect 
appropriate  computer  security  controls  and  safeguards,  that 
NBS  prepare  physical  and  personnel  standards  for  protecting 
Federal  ADP  systems  according  to  their  sensitivity,  and  that 
Federal  agencies  improve  coordination  of  computer  resource 
protection    efforts    [Ref.    6:    p.    276]. 

In  response  to  these  Congressional  recommendations, 
OME  issued  Transmittal  Memorandum  No.  1  to  Circular  A-7  1  in 
July      1978      [Ref.    7].  In      announcing      this      comprehensive 

Federal  computer  security  program,  OMB  Director  James  T. 
Mclntyre,    Jr.,    sail, 

Ccmouter  technoloay  now  impaots  almost  every  facet  of 
American  life.  The  protection  of  the  technology  against 
unwarranted,  unautiorized  and  illegal  users  is  a'maior 
challenge.  This  proaram  addresses  that  challenge  in  the 
Federal   Community.       ["Ref.    8] 

The  Transmittal  Memorandum  requires  each  agency 
computer  security  program  :d  satisfy  the  following 
requirement  s: 

•  Conduct  a  perioiic  risk  analysis  for  each  computer 
installation    operated    either    in-house    or    commercially. 

•  Assign  responsibility  for  security  to  a  management  offi- 
cial k.n  cwiedgeable  in  data  processing  and  security 
matters. 
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•  establish  a  management  control  process  to  ensure  that 
appropriate  administrative,  technical,  and  physical  safe- 
guards are  inccrpor  at  ei . 

•  Ensure  that  appropriate  security  requirements  are 
included  in  specifications  for  the  acquisition  or  opern- 
tior.  of  computer  resources. 

•  Establish  personnel  security  policies  for  screeninq  all 
individuals  participating  in  the  desiqn,  operation,  or 
maintenance  of  or  having  access  to  Federal  computer 
systems. 

•  Conduct  periodic  audits  or  ^valuations  and  recertify  the 
adequacy  of  the  security  safeguards  of  each  operational 
sensitive  application. 

•  Ensure  that  appropriate  contingency  plans  are  developed, 
maintained,  and  tasted  to  provide  for  continuity  of  oper- 
ations should  events  disrupt  normal  operations.  [Hef.  7: 
p.  3] 

Also  in  1978,  Presidential  Directive  Number  24  was 
issued  which  transferred  the  functions  of  the  White  louse 
Office  of  Telecommunications  Policy  tc  the  Department  of 
Defense  (DOD)  and  Department  of  Commerce.  DOD  was  -asked 
with  telecommunications  policy  relating  to  national 
security.  All  other  te leconn an ications  policy  functions 
were  assigned  to  the  National  Telecommunications  and 
Information  Administration  under  the  Department  of  Commerce. 

Because  DOD  is  the  largest  Federal  agency  in  terms 
of  personnel  strength,  budget  size,  and  nuaber  of  computers, 
it  is  the  most  affected  by  tha  Federal  policies  discussed 
above.  DOD  reacted  to  OMB  Circular  A-108  by  publishing  DOD 
Directive  5U00.11  [Ref.  9].  This  directive  established  a 
DOD  Privacy  Board  with  oversight  review  authority,  and 
included  guidelines  for  safeguarding  personal  data  in  ADP 
systems  as   an   appendix.    D3D   approached   Circular   A-71 
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somewhat  less  decisivaiy.  Sinsa  DOD  had  been  involved  with 
the  protection  of  classified  data  for  years,  it  sought  to 
apply  the  framework  of  A-71  id  ths  existing  classified  arena 
and  integrate  the  aiditionai  protection  requirements  for 
unclassified  ADP  systems.  rhs  objective  of  DOD  was  to 
develop  an  overall  systematic  concept  to  security  that 
applied  safeguards  tD  each  ADP  system  commensurate  with  the 
sensitivity  of  the  data  being  processed.  DOD  forwarded  the 
approach  to  OMB  in  a  memorandum  dated  30  January  1 98 D  and 
appropriately  entitled  "A  Comprehensive  Information  Security 
Program."  By  the  issuance  of  this  memorandum,  all  military 
departments  were  tasked  to  establish  formal  risk  management 
and  computer  security  programs  is  delineated  in  Ref.  7. 

In  reaction  to  the  proposed  comprehensive  DDD  AD? 
Security  Program,  the  Department  of  the  Navy  (DON)  promul- 
gated OPNAVINST  5239.1,  which  assigned  spacific  ADP  security 
responsibilities  within  the  Navy  and  established  Designated 
Approving  Authorities  (DAA).  The  current  version  of  this 
instruction  [Ref.  10]  directs  aach  Navy  activity  to  assign 
ADP  security  responsibilities,  establish  an  Activity  ADP 
Security  Program,  implement  a  formal  Risk.  Management 
Program,  and  be  accredited  by  the  appropriate  DAA. 

OPNAVINST  5239. 1  A,  together  with  the  Naval  Material 
Command  (NAVMAT)  and  the  Naval  Supply  Systems  Command 
(NAVSDP)  implementations,  should  after  a  period  of  time 
substantially  increase  the  protection  afforded  to  DON  ADP 
systems.  The  reguirenents  for  a  Risk  Management  Program  are 
summarized  in  Table  I,  which  lists  the  regulations  and 
reports  published  in  the  last  decade. 

2-   Operational  Requirements 

In  order  to  establish  and  manage  an  Activity  ADP 
Security  Program,  it  is  encumoant  on  activity  top  management 
(Commander,    Commanding  Dfficec,    Officer   in  Charge,    or 
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TABLE  I 
Federal/DOD/DD N  Regulations  on  ADP  Secarity 

1974  -  Privacy  Act  of  1974  (Public  Law  93-579) 

I^S  -  OMB  Circular  No.  A-108,  "Resoonsibilities  for  the 
Maintenance  of  Recoris  about  Individuals  by 
Federal  Agencies,"  1  JuLy  1975 

-  DODD  5400.11,  "Personal  Privacy  and  Rights  of 
Individuals  Regarding  their  Personal  Records,"  4 
August  1975 

-  NAVMATINST  5211.2,  "Personal  Privacy  Act  ar.d 
Rights  of  Individuals  Regarding  their  Personal 
Records,"  26  September  1975 

-  NAVSOPINST  52  11.1  «,  "Personal  Privacy  Act  and 
Rights  cf  Individuals  Regarding  their  Personal 
Records  (Privacy  Act  of  1974,  Puolic  Law  93-579)  ," 
18  November  1975 

1976  -  GAO   Report,    "Improvement    Nee2=i   in   Managing 

Automated  Decisionmaking   by  Computers   Throughout 
the  Federal  Government,"  April  1976 

-  GAO  Report,  "Computer-Related  Crimes  in  Federal 
Programs,"  April  1976 

-  GAO  Report,,  "Managers  Need  to  Provide  Better 
Protection  ror  Federal  Automatic  Data  Processing 
Facilities,"  lay  1976 

-  Senate  Committee  on  Government  Operations, 
"Computer  Aoises  -  Problems  Associated  witn 
Computer  Technology  in  Federal  Programs  and 
Private  Industry,"  "June  1976 

1977  -  Senate  Committee  on   Government  Operations,   "Com- 

puter Security  in  Federal  Programs,"  February  1977 

-  NAVMATINST  5510.17,  "Sacurity  of  ADP  Systems,"  22 
March  1977 


1978  -  OMB  Circular  No.   A-71,  Transmittal  Memorandum  No. 

1,    "Security   of  Felerai   Automated   Information 
Systems,"  2  7  July  197  3 

1979  -  SECNAVINST  5211.1C,   "Personal   Privacy  and  Riahts 

of   Individuals   Pertaining   to   Their   Personal 
Records,"  4  December  1931 

1980  -  DOD   Memorandum,    "A    Comprehensive   Information 

Security  Program,"  30  January  1980 

-  NAVSUPINST  5510.6A.  "Security  Reguirements  for  ADP 
Systems,"  28  lay  1980 

1982  -  OPNAVINST   5239.  1A,     "Department   of    the   Nav 
Automatic   Data   Processing  Security   Program," 
August  1982 
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Director)  to  implement  a  Risk  Management  Program.  In  the 
process  of  formalizing  'his  program,  top  management  must 
establish  ADP  security  policy  with  explicit  regard  to 
OPNAVINST  5239. 1A  and  the  unique  requirements  and 
constraints  of  the  activity  ADP  systems.   * Ref .  10:  p.  1-2] 

Since  activities  hava  invested  heavily  in  computer 
resources,  they  oftan  desire  to  maximize  the  utilization  of 
their  resources  by  sharing  tham  among  usees,  both  internal 
and  external  to  the  activity.  Each  usar  has  a  different 
neec-to-kno w  and  naei- to-ut iliza  criteria  for  accessing  his 
information.  This  requires  that  individual  user  data 
integrity  be  assured,  while  concurrently  providing  shared 
access  to  the  ADP  system.  For  example,  an  ADP  activity 
might  furnish  servicas  to  both  fiscal  and  logistic  users, 
each  of  which  expects  its  assats  to  be  protected  and  avail- 
able upon  demand.  The  task  of  simultaneously  sharing  and 
protecting  an  ADP  system  is  the  responsibility  of  the 
activity  providing  automated  support. 

Ref.  10  requires  that  aach  Navy  ADP  activity  be 
accredited  for  operational  usa.  By  accrediting  an  activity, 
the  DAA,  which  in  some  cases  is  the  activity  Commanding 
Officer,  acknowledges  that  fchs  risk  of  operating  the  lata 
processing  environment  is  acceptable,  in  light  of  the  activ- 
ity's mission  and  the  users'  dependence  on  automated 
support,  and  approves  the  systam  for  operational  use.  To 
obtain  accreditation,  top  management  must  quantify  the  oper- 
ational risk  and  implement  an  Activity  ADP  Security  Plan. 
The  Risk  Management  Program  dascribed  in  Ref-  10  and  further 
explained  by  this  tiiasis  is  the  *ool  used  by  top  mangement 
to  quantify  the  risk  present,  evaluate  the  cost- 
effectiveness  of  proposed  countarmeasures,  and  provida  for 
recurring  review  of  the  activity's  ADP  security  posture. 
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C.   INTRODUCTION  TO  SPLICE 

The  stock  Point  Logistics  Integrated  Commur.ica1:  ior.s 
Environment  (SPLICE)  is  a  NAVSj"?  Project  designed  to  inte- 
grate all  interactive  processing  and  telecommunications 
required  by  current  and  projected  applications  systems 
operating  within  tae  Uniform  Automated  Data  Processing 
System  for  Stock  Points  (JADPS/5P) .  The  SPLICE  Project  will 
use  standard  minicomputers  and  nodular  software  components. 
A  "f oreground/backgrour.d"  concept  will  be  implemented  with 
SPLICE  minicomputers,  which  will  serve  as  a  front-end- 
processor  for  tne  existing  stock  points  medium  sized 
Burroughs  systems.   "Sef.  11:  p.  1] 

More  than  twenty  new  applications  systems  under  develop- 
ment and  the  current  UADPS/SP  system  comprise  the  "SPLICE 
Umbrella."  These  systems  will  require  considerable  interac- 
tive and  telecommunications  support  at  more  than  fifty 
UADPS/S?  activities.  SPLICE  will  provida  a  responsive  and 
economical  support  capability  without  saturating  the  current 
Burroughs  mainframes,  and  will-  simplify  the  eventual  main- 
frame replacement  [Ref.  11:  p.  1 ].  SPLICE  will  present  a 
user  oriented  environment  whici  will  provide  many  standard 
operating  functions  such  as  terninal  management,  communica- 
tions management,  database  nanagement,  and  peripheral 
management.  Additionally,  there  will  be  nany  support  func- 
tions such  as  standard  software  tools  (compilers,  etc.), 
recovery  management:,  and  security-  The  existing  Burroughs 
mainframes  will  provide  large  file  processing  functions  and 
report  generation. 

As  seen  in  Figure  1.1,  the  evolution  of  computer  tech- 
nology has  resulted  in  the  design  and  implementation  of  very 
complex  and  sophisticated  automated  environments.  The  risk 
of  operating  these  new  environments  is  directly  proportional 
to  their  overall  complexity.  As  a  point  of  reference,  the 
operational  SPLICE  Network  will  fall  at  the  very  high  end  of 
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the  technology  and  complexity  scales.  The  Navy's  increased 
operational  dependencies  on  automated  systems  demand  that 
the  risk  in  SPLICE  bs  evaluated  and  managed  at  an  acceptable 
level. 

D.  OBJECTIVES    OF    RESEARCH 

Research  by  Naval  Postgraduate  School  faculty  and 
students  on  the  SPLICE  Project  is  concerned  with  systems 
analysis  and  preliminary  design  proposals  for  many  of  the 
functional  areas  of  SPLICE.  Phis  thesis  defines  a  Risk 
Management  Program  to  evaluate  and  manage  the  risk  associ- 
ated with  the  operation  of  SPLICE.  The  methodology  proposed 
draws  upon  current  government  and  industry  technigues  and 
conforms  to  existing  DON  and  ^A7SrJ?  guidance. 

Ref.  11  tasked  NAV5UP  D'4  1  5  and  the  Fleet  Material 
Support  Office  (FMSOj  94  with  conducting  a  risk  analysis  of 
the  SPLICE  system.  It  is  intended  that  the  Risk  Management 
Program  proposed  in  this  thesis  be  used  as  a  tool  to  quan- 
tify the  risk  in  SPLICE.  Together  with  information  about 
and  simulation  of  tie  eventual  operational  SPLICE  activi- 
ties, -his  tool  can  oe  used  to  identify  those  initial  design 
specifications  needed  to  reduce  the  risk  in  SPLICE. 

E.  LIHITATIONS    AND    ASSUMPTIONS 

y.      Defense    Data    Network 

The  original  SPLICE  specifications  reguired  the 
Network  Interface  Subsystem  to  provide  access  to  the  AUTODIN 
II      Network   [Ref.    13:         p.       57].  On    2      April    1982      Deputy 

Secretary  of  Defense  Carlucci  directed  the  termination  of 
the  AUTODIN  II  prograa  and  the  immediate  development  of  the 
Defense  Data  Network  (DDN)  ^Ref.  14].  It  is  current  DOD 
policy  that  all  data  communications  users  will  be  integrated 
into    the    DDN. 
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It  is  assuaei  that  ths   SPLICE  Network,  will  comprise 

a  "community  of  interest"  within  the  DDN.    A  brief  '??::ir- 

tion   of  the  DDN  and   a   summary  of   the  security  features 
provided  by  the  DDN  is  included  as  Appendix  C. 

2.   Level  II  Data 

It  is  assumed  that  tha  data  processed  within  the 
SPLICE  Network  is  Laval  II  data,  which  is  defined  in  Ref.  10 
as  unclassified  data  requiring  special  protection.  Since 
the  SPLICE  application  systems  will  be  processing  financial 
and  other  management  lata  which  is  by  definition  "Sensitive 
Eusiness  D  at  a,"  it  requires  protection  for  reasons  other 
than  being  classified  or  personal  data.  It  is  judged  that 
the  potential  impact  of  modification  or  destruction  of  the 
data  is  severe  enough  to  justify  a  greater  degree  of  protec- 
tion than  required  for  other  unclassified  information. 

3-   Activity  ADP  Security,  Plan 

The  majority  of  SPLI3E  configurations  will  be 
located  at  Navy  ADP  activitias,  which  ara  subject  to  the 
Department  of  the  Na/y  ADP  Security  Progran  [Ref.  10:  p.  3]. 
Although  the  proposals  set  forth  in  this  thesis  follow  the 
guidance  of  Ref.  10f  they  are  concerned  only  with  the  risk 
management  of  the  SPLICE  configuration (s)  and  will  not 
constitute  an  Activity  ADP  Security  Plan.  The  Activity  ADP 
Security  Plan  must  be  much  more  comprehensive  in  order  to 
implement  the  overall  Activity  ADP  Security  Program.  In 
particular,  Appendix  J  of  Ref.  10  outlines  the  mandatory 
minimum  requirements  for  DON  \DP  activitias.  Additional 
minimum  security  requirements  for  SPLICE  are  given  in  Refs. 
11  and  15. 
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A£Elicaticns  Software  Security. 


Each  applications  soft* 
own  unique  internal  security  an3 
activity  software  development 
applications  software  integrity 
tions  of  money  figures  (such  as 
fractions  of  cents,  if  any)  ani 
unique  audit  trails  (such  as  ti 
File  in  UADFS/SP).  kt  a  mininun 
incorporate  security  and  audit  c 
of  Eef.  10-  Applications  proc 
adhere  to  NAVCOMPTINST  7003. 
Sy.st.ems;  Standard  criteria  for  A 


are  system  must   provide  its 

data  integrity,  adhering  to 

policy.     Examples  of   such 

considerations  are  computa- 

what  to  do   with  remaining 

Maintenance  of  application- 

e  Transaction  Reconstruction 

,  applications  software  must 

ontrols  listed  in  Appendix  I 

essing  financial  data  should 

DP  internal  control  of. 
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II.  OVERVIEW  OF  RISK  MANAGEMENT 

A.   RISK  MANAGEMENT  TERMINOLOGY 

Before  proceeding  with  a  discussion  of  the  functional 
phases  of  risk  management,  it  is  essential  that  the  terms 
risk,    threat,     val nerability ,    and   countermeasure   be 

explained. 

1-   Risk 

In  Webster's  Collegiate  Dictionary,  risk  is  defined 
as  the  possibility  of  loss  or  injury;  a  dangerous  element; 
or  the  degree  of  probability  of  a  loss.  Unfortunately,  the 
term  risk  is  not  a  universally  de-fined  term.  Risk  is 
perceived  differently,  depending  on  the  circumstance  or 
community. 

The  insurance  industry  uses  the  ilea  of  an  "insur- 
able risk."  A  oonpany  identifies  both  the  known  and 
uncertain  elements  of  operating  a  business  and  minimizes 
their  potential  loss  by  buying  insurance.  The  insuring 
agent,  using  empirical  and  statistical  data,  sells  protec- 
tion to  the  company  in  the  form  of  financial  compensation 
should  its  assets  be  lost.  !:>  determine  how  much  risk  is 
involved,  the  agent  relies  on  historical  data,  prediction 
models,  and  business  experience.  Unfortunately,  the 
computer  industry  is  relative!/  new  and  little  analytical 
data  is  available  fsr  assessing  the  areas  and  extent  of 
potential  security  risks. 

In  business  economics,  there  are  two  types  of  risk: 
speculative  and  pure.  When  a  basiness  invests,  and  there  is 
a  degree  of  uncertainty  as  to  whether  that  investment  will 
result  in   a  gain,   the  risk   is  speculative.    If   the  only 
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possible    outcome   is      either    loss    or    no    change,         the    risk   is 
classified    as    pure. 

In  the  context  of  AD?  Security,  only  a  pare  risk  can 
exist.  Risk  within  the  data  processing  coamunity  is  defined 
as  the  likelihood  of  a  loss  ani  the  expected  amount  of  -hat 
loss    with    respect   to   the   assets    of    an    activity. 

2.      Threat 

H.  Stephen  Morse  of  the  System  Development 
Corporation  defines  a  threat  as  any  action,  event,  or 
circumstance,  the  occurrence  of  which  is  likely  to  adversely 
affect  the  assets  of  an  activity.  Threats  exist  in  general 
because  of  the  unpredictability  of  the  real  world  and 
people.  The  presence  of  a  threat  does  not  equate  to  harm  or 
loss.  For  that  to  happen,  there  must  be  a  successful  attack 
by  a  threat  agent  using  a  specific  technique,  methodolgy,  or 
spontaneous  occurrence. 

Threat  agents  are  classified  as  natural  environ- 
mental factors  (tornado,  flood,  fire,  etc.),  authorized 
users  (programmers,  operators,  etc.),  or  hostile  agents 
(anyone  net  an  authorized  useri  .  A  threat  agent  causes  a 
threat  to  be  realized  by  attacking  the  assets.  The  attack 
can  impact  these  assets  in  at  most  four  areas:  modification, 
destruction,  disclosure,  or  denial  of  service.  Whether  the 
attack  renders  harm  d:  Loss  to  the  activity  is  dependent 
upon  the  threat  agent  successfully  penetrating  the  existing 
countermea sures  ani  exploiting  weaknesses  (vulnerabilities) 
in  the  data  processing  environment. 

The  threats  facing  an  activity  can  be  a  function  of 
its  geographic  location,  personnel  workforce,  processing 
mode,  physical  facilities,  or  cDnputer  system  configuration. 
Since  these  elements  are  constantly  changing,  threats  are 
considered  dynamic  ani  should  b=  continually  monitored. 
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[Ref.  16:  p.  174  ] 


Figure  2. 1    Some  Typical  Threats  and  Their  Usual  Defense. 

Perhaps  the  easiest  way  to  understand  threat  is  by 
an  example.  Although  the  existence  of  threats  is  beyond  our 
control,  a  threat  will  not  necessarily  materialize  or  cause 
harm.  There  is  always  the  threat  of  a  fire,  but  that  does 
not  mean  there  will  be  a  fire.  The  occurence  of  a  fire  and 
the  extent  of   damage  a  fire  woiid  cause  impends   in  part  on 
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:he   weaknesses    in   the    facility. 


'he    weakness,    in    -his    cas?, 


is   the   lack    of    fire      prevention    aeasures.         Figure    2.1    shows 
some  typical  threats   and   their   usual   defense. 

3.      Inlner ability 

OFNAVINST  5239. U  iefines  a  vulnerability  of  a 
computer  system  as  a  weakness  ii  its  physical  layout,  organ- 
ization, procedures,  hardware,  or  software  that  may  be 
exploited  to  inflict  harm.  As  with  a  threat,  the  presence 
of  vulnerability  does  not  in  itself  cause  harm;  a  vulner- 
ability is  merely  the  conditioi  or  set  of  circumstances  of 
which  The  threat  agent  can  take  advantage  zd  inflict  damage. 
fRef.    10:    p.   A-17] 

The  vulnerabilities  of  a  computer  system  increase 
directly  with  its  conplexity;  remotely  accessed  resource- 
sharing  computer  systems  that  allow  remote  jcb  entry  are 
significantly  more  likely  to  have  weaknesses  than  a  dedi- 
cated, batch-processing,  stand-alone  system  with  no  remotely 
located    terminals.  Figure    2.2    illustrates      some    potential 

vulnerabilities    of   a    oomputer   system. 

One  purpose  Df  evaluatiig  a  data  processing  environ- 
ment is  to  identify  all  vulnerabilities  existing  in  the 
facility,  system,  or  operation.  By  conducting  a  thorough 
analysis  of  identified  weaknesses  and  weighing  each  of  the 
probabilities  of  a  successful  attack  by  a  threat  agent,  the 
vulnerabilities  of  the  data  processing  environment  can  be 
measured.  Vulnerabilities,  uilike  threats,  are  generally 
under  the  control  or  influence  of  the  data  processing 
management,  and  can  be  modified  to  reduce  the  severity  of  an 
attack. 
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**•   Co  jiiitermeasucg 

The  words  :ounteri=asur35,  safeguards,  protective  or 
backup  measures,  and  control  mechanisms  are  often  viewed  as 
being  synonymous.  A  counter measure  is  any  protective 
action,  device,  procsiure,  technique,  or  aechanism  that  when 
implemented  reduces  the  activity's  vulnerability  to 
successful  attacks.  These  corrective  features  are  designed 
and  developed  to  protect  the  assets  of  an  activity.  The 
purpose  of  a  count  ecu easure  is  to  either  reduce  the  prob- 
ability of  a  successful  attack  or  minimize  the  impact  of  an 
at~ack.  C  cur  t  er  it*. e  a  ~  1  r  - s  are  therefore  technical  cr  manage- 
rial  mechanisms  foe  controlling  the  risk  to  which  an 
activity  is  exposed.  Some  examples  are  contingency  plans, 
backup  copies  of  software,  acoess  control  procedures,  and 
audit  trails. 

As  shown  by  Figure  2.3,  risk  management  is  concerned 
with  the  interaction  among  the  -eras  just  defined.  Risk  is 
the  extent  and  probaoility  of  Idss  due  to  the  manifestations 
of  threats  (attacks)  it  points  of  vulnerability  in  light  of 
installed  count ermeasu  res. 

B.   RISK  MANAGEMENT:  \    FUNCTIONAL  APPROACH 

Risk  management  with  respect  to  computers  is  a  new 
discipline  that  provides  giancifiable  technigues  for 
assessing  the  risk  of  operating  a  computer  system  in  light 
of  existing  protection  measures,  and  determining  the 
reguirement  for  additional  countermeasures  to  protect  that 
system.  Leading  authorities  in  the  data  processing  industry 
are  using  various  technigues  foe  analyzing  risks.  However, 
most  agree  on  a  formal,  four-phased  approach  to  risk  manage- 
ment: risk  analysis,  management  decision,  risk  control,  and 
operational  continuity. 
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Figure  2,3    Factors  Df  Risk  Management. 
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For  a  risk  management  program  to  effectively  enforce  the 
ADP  security  policies  and  control  the  AD?  security  poseurs 
of  an  activity,  a  total  comnitment  is  needed  from  top 
management.  High  level  attention  will  improve  the  coopera- 
tion across  interdepartmental  lines  and  will  foster  an 
increased  security  awareness.  Fop  management  commits  itself 
to  a  risk  management  program  by  making  resource  allocations 
in  terms  of  both  skilled  manpower  and  budgetary  allotments 
and  by  integrating  security  objectives  into  the  existing 
managerial    responsibilities    at    all    levels. 

Top  management  is  also  responsible  for  promulgating 
ociicy  on  the  frequency  and  conditions  for  initiating  the 
risk  analysis  phase.  According  to  Ref.  10,  a  risk  analysis 
will  be  conducted  at  least  ever/  five  years,  or  whenever  in 
the  -judgement  of  top  management  a  system  configuration  or 
facility  -change  has  been  effected  that  warrants  a  requanti- 
fication   of   the    risk. 

1«      Ei.HJS  Analysis 

The  quantification  of  risk  is  not  new.  As  early  as 
the  seventeeth  and  eighteenth  centuries,  noted  men  sucn  as 
Pascal,        Bernoulli,  and      Bayes      applied        risk      analysis 

techniques  to  "games  of  caance."  Risk  analysis  has  recently 
been  applied  to  the  data  processing  environment,  expanding 
the  "game  of  chance"  from  computing  the  odds  for  a  win  to 
quantifying  the  probability  of  loss  or  harm  for  a  computer 
system. 

The  purpose  of  conductiig  a  risk  analysis  of  a  data 
processing  environment  is  to  quantify  the  damage  and  opera- 
tional impact  resulting  from  the  successful  attack  by  a 
threat  agent  and  the  likelihood  of  such  an  attack  occurring 
[Ref.  17:  p.  8].  The  analysis  produces  an  annual  loss 
expectancy  (ALE)  value,  which  is  a  quantitative  estimate  of 
the    potential      average    yearly    financial    loss      resulting    from 
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any  accidental  or  Intentional  unauthorized  modification, 
destruction,  disclosure,  or  denial  of  service.  This  ALE 
value  is  a  baseline  for  assessing  the  ADP  security  posture 
of    an    activity. 

As  shown  by  Figure  1.1,  the  risk  an  activity  faces 
is  directly  proportional  to  the  complexity  of  its  data 
processing    environment.  Because    of   this,         top   management 

bases  the  scope  and  depth  of  the  risk  analysis  on  the 
complexity  of  the  particular  environment  being  evaluated. 
Some  factors  that  ace  pertinent  to  the  decision  are  the 
value  of  the  physical  facility,  the  value  of  the  data  (both 
internally  to  the  activity  and  externally  to  others),  the 
configuration  of  the  A  DP  system,  and  the  oriticaiity  of  the 
data  processing  service  to  the  activity1 s  and  users' 
missions. 

The  risk  analysis  technique  attempts  to  predict 
future  risk  exposure  of  an  activity  based  on  a  thorough 
evaluation  of  its  assets,  threats,  vulnerabilities,  and 
existing  countermeasur es.  This  evaluation  relies  heavily  on 
the  professional  experience  an!  technical  knowledge  of  the 
risk  analysis  team.  For  this  reason,  it  is  vital  that  the 
team  be  drawn  from  both  the  lata  processing  department  and 
the  users'  departments  in  order  to  take  advantage  of  their 
diverse      backgrounds      and    technical      expertise.  The      team 

members  should  be  highly  skills!  professionals,  whose  selec- 
tion will  substantially  influence  the  quality  of  the  final 
risk  analysis  product.  Additionally,  the  risk  analysis  team 
must  be  supported  at  all  levels  if  the  analysis  is  to  accu- 
rately   reflect    the   security   posture    of   the    activity. 

2.       Management    Decision 

In  this  phase  top  management  decides,  based  on  the 
risk  analysis,  the  activity's  mission,  and  the  users'  degree 
of   dependence   on   automation,    if    the    existing   countermeasures 
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provide  sufficient  protection.  3efore  making  this  decision, 
top  management  revisits  the  risk  analysis  to  determine  if 
appropriate  assumptions  wars  made  and  operational 
constraints  were  considered.  The  risk  analysis  quantified 
the  "current  level"  of  risk  associated  with  operating  the 
existing  computer  system  and  documented  the  activity's  ADP 
security  posture.  The  risk  analysis  should  be  presented  to 
top  management  in  such  a  manner  that  decisions  can  be  made 
in  relation  to  the  documented  threats,  vulnerabilities,  and 
cour.termea  sures . 

At  this  jur.3t.ion,  tha  Risk  Management  Program  can 
follow  one  cf  two  directions,  contingent  on  the  decision  of 
top  management.  If  top  managaaent  judges  the  current  level 
of  risk  as  acceptable,  than  the  Operational  Continuity  Phase 
is  entered.  By  progressing  iirectly  to  that  phase,  top 
management  is  explicitly  acknowledging  that  existing  control 
practices  and  procedures  ara  sufficient  and  the  current 
security  level  is  to  be  maintained.  On  the  other  hand,  if 
top  manaaement  decides  that  the  current  level  of  risk  is 
unacceptable,  then  the  Risk  Zontrol  Phase  is  initiated. 
This  means  that  top  management  is  not  willing  to  tolarate 
the  risk.  Before  the  Risk  Control  Phase  is  begun,  top 
mar.aqement  should  assign  a  risk  control  team  and  provide 
guidance  abouts  thos=  deficiencies  of  greatest  concern.  The 
risk  control  team  should  be  composed  of  a  greater  proportion 
of  data  processing  technicians  chan  the  risk  analysis  team. 

3-   Hisk  Control 

The  function  of  this  phase  is  to  propose  to  top 
management  an  optimal  set  of  countermeasures  that  have 
proven  cost-effective  and  technically  feasible.  The  coun- 
termeasures needed  to  bring  the  risk  of  operating  to  an 
acceptable  level  are  selected  from  a  combination  of  risk 
avoidance  and  reduction  tschnigues. 
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Within  the  iata  oroceseing  environment,  a  risk  is 
avoided  by  determinin g  that  a.  particular  ADP  specification 
should  be  abandoned,  redesigned,  or  deferred  because  the 
potential  harm  is  too  great  to  be  controlled  with  existing 
technology.  Councecm easures  to  reduce  risk  fall  into  three 
basic  categories: 

•  Protective  measures  which  reduce  the  damaging  effects  of 
external  events. 

•  Control  measures  which  reduce  the  likelihood  of  unde- 
tected  errors    or    fraudulent    modif ications   and 

U"»ciat.ilOr  iZ6vl     uiSC.D  SUITr  • 

•  Back-up  (contingency)  measures  which  provide  alternative 
means  for  carrying  on  the  mission  of  an  activity  subse- 
quent tc  an  event  which  lisrupts  normal  operations. 
[Ref;    18:   p.    2214  1 

After  top  management  selects  and  approves  those 
measures  that  have  the  greatest  potential  of  minimizing  the 
overall  losses,  the  risk  control  team  prioritizes  them  for 
implementation.  This  phase  is  complete  wnen  top  management 
accepts  the  set  of  proposed  additional  coantermeasures  and 
approves   their    implementation    plan. 

**•      Operational    Continuity. 

The  Operational  Continuity  Phase  is  initiated  either 
after  completion  of  the  Risk  Control  Phase  or  immediately 
following      the      Management      Decision    Phase.  If      the      Risk 

Control  Phase  was  executed,  resources  are  dedicated  in  this 
phase  to  carrying  oat  the  action  plan  developed  for  imple- 
menting  the   approved   additional    countermeasures. 

During  this  phase,  tha  DAA  makes  the  technical  and 
managerial  policy  decision  regarding  the  accreditation  of 
the  activity.  That  decision  is  made  immediately  if  no  Risk 
Control   Phase    was   executed,      or      after   the    implementation   of 


34 


additional    countermeasurss.  Regardless   of    whether      or    not 

additional  countermea surs  s  are  being  implemented,  the 
process  of  risk  management  continues.  This  ongoing  effort 
is  considered  esseitial  to  preserving  the  ADP  security 
posture  of  the  activity  and  includes  oDntinual  review, 
audit,  and  evaluation  of  the  lata  processing  environment. 
This  phase  is  terminated  when  it  is  deemed  necessary  to 
reinitiate  the  Risk  Analysis  Phase  because  either  a  five 
year  time  interval  has  passed  or  the  polioy  of  top  manage- 
ment  so   dictates. 
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III.     RISK    MAN&SE8ENT    PROGRAM 

The  proposed  Risk  Management  Program  furnishes  a  frame- 
work which  is  tailored  to  tas  unique  aspects  of  the  data 
procsssing  environaeit .  The  fDiindation  of  this  program  is 
taken  from  Refs.  2  and  10  an3  the  recent  experiences  of 
industry.  Quantitative   techniques      are  used      in   the      Risk 

Analysis   and  Risk  Control   Phases.  These    techniques    do    not 

utilize  exact  values;  instead,  values  are  scaled  by  orders 
of  magnitude.  The  use  of  relative  magnitude  is  to  accomo- 
date the  lack  of  enpiricai  data,  incomplete  knowledge  on  the 
future  likelihood  of  attacks,  and  inconclusive  proof  of  the 
effectiveness    of   count ermsasures . 

As  a  first  step  ia  establishing  a  formal  Risk  Management 
Program,  it  is  recommended  that  activity  top  management 
implement  a  managerial  structure  which  includes  an  ADP 
Security    Staff    as      described    in    Ref.       10.  The    activity   is 

directed  to  the  Comnander,  Naval  Data  Automation  Command 
(COMNAVDAC)  for  technical  assistance  in  conducting  a  risk 
analysis.  Within  the  DDH,  C3MNAVDAC  is  responsible  for 
providing  assistance  as  requested  and  with  ensuring  that 
risk  management  expertise  is  shared  across  activity 
boundaries. 

This  chapter  i=  broken  into  the  phases  of  a  Risk 
Management  Program  and  is  intended  to  meet  two  objectives. 
The  first  is  to  describe  in  a  cohesive  manner  the  philosophy 
of  each  phase.  The  second  is  to  give,  where  necessary, 
specific  implementation  oonsiderations  independent  of  the 
philosophy. 
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A.       RISK    ANALYSIS 

According   to   Rsf.       10,    th^re    are   three   distinct    steps  in 
a  risk   analysis.        These   steps,    as    shown    ia    Figure    3.1,    must 


ksset  Ldss 
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Threat  and 
Vulnerability  Evaluation 


'on  put  at  ion  of  the 
Aaaual  Lose  Expec- 


Total 
ancy 


Figure  3.1   The  Major  Steps  of  Risk  Analysis. 

be  completed  in  sequential  order.  The  purpose  of  the  Risk 
Analysis  Phase,  is  to  quantify  in  accordance  with  the  policy 
guidelines  from  top  management  the  risks  of  a  specific  data 
processing  environment  in  relation  to  its  threats,  vainer- 
abilities,  and  existing  coini:  ermeasures.  The  following 
conceptual  model  and  implementation  considerations  elaborate 
on  how  this  quantification,  is  performed. 
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1.   Model 

j Ji g  risk  analysis  model  is  a n  abstr^cticn  of  "the 
risk  analysis  process  prasentei  in  Appendix  E  of  Ref.  10. 
It  takes  into  account  the  work  of  Robert  H.  Courtney 
[Ref-  3],  NBS  [Ref.  17],  and  Jerry  Fitzgerald  [Ref.  19]. 
The  model  allows  one  to  systematically  quantify  asset  losses 
and  attack  frequencias  oa  an  annualized  basis  and  to  calcu- 
late from  these  tha  total  annual  loss  expectancy  (ALE)  of  an 
activity. 

a.   Asset  Loss  Determination 

This  step  identifies  all  of  the  assets  within  an 
activity  and  quantifias  the  activity's  loss  should  they  be 
harmed.  The  degre?  to  »hich  assets  should  be  separately 
identified  is  addressed  in  tha  implementation  considera- 
tions. In  addition  to  naming  an  asset,  a  textual 
descriotion   is  written  to  dDcamer.t   hew   that  named   asset 


could  be  impacted   by  threats  i.i  general, 


Next, 


each 


named  asset,  fcur  loss  values  ire  determined,  one  for  each 
threat  impact  area.  The  four  threat  impact  areas  are  modi- 
fication, destruction,  disclosure,  and  denial  of  service. 
Each  loss  value  is  an  estimation  in  dollars  of  what  an 
activity  will  lose  if  one  attack  is  completely  successful  in 
causing  harm  in  that  impact  area  to  the  asset.  Put  another 
way,  given  that  there  is  a  ons  hundred  percent  probability 
of  one  successful  attack,  how  much  is  an  activity  willing  to 
pay  to  prevent  that  attack?  This  step  is  completed  by 
transforming  each  loss  determination  into  a  loss  rating 
[Ref.  17:  p.  10].  The  modeL  component  representing  this 
step  is  summarized  in  Table  II. 
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TABLE    II 
Asset    Loss   Deternination    Model 

The  loss  detsrmin  ^tian  function,  L(i,A),  is  an 
empirical  estimation  of  loss,  in  dollars,  of  asset 
A  in  impact  area  ir  rounied  to  the  nearest  expo- 
nential value   of    ten. 

The    function   is    expressed    as: 

L(i,A)    =    function    [D(A),    N(A)],    rounded 

Where: 

i     =  the  threat  impact  area   (modification,  des- 
truction, uis3i.03ir;f  cr  d£niaj.  di  service) 

A    =  the  uniqie  name  of  an  asset 

D  (A)  =  the  description  of  iow  asset  A  could  be  af- 
fected by  threats 

N(A)  =  the  number  of  identical  assets  A    subject  to 
the  same  threats 

The  loss  rating  function  is  a  logarithmic  mapping 
from  L  (i,A)  onto  an  ordinal  integer  eoale  ranging 
from  0  to  8.  Tie  zero  ratine  indicates  asset  A  is 
not  affected  in  i  particular " impact  area  i. 


LOSS  (i, A)  =  logi;j[L(i,A)  ] 


b.       Threat    and    Vulnerability    Evaluation 

This  step  identifies  each  threat  which  could 
possibly  affect  the  assets  of  in  activity,  provides  perti- 
nent textual  descriptions,  aid  expresses  the  probability  of 
an    attack    with      an   annualized    frequency  rating.  The    first 

description  defines  the  threat  and  enamerates  specific 
threat  agents.  The  eeconi  description  discusses  the  vulner- 
abilities which  are  susceptible  to  attacks  by  threat  agents. 
The      last      description      describes      existing      countermeasures 
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installed  tc  counter  those  attacks.  Examples  of  threats 
commom  to  the  current  minicpipater  environment  are  iienti- 
fied  in  the  implementation  consi  Orations. 

Since  the  realization  of  a  threat  can  have  an 
impact  assets  in  four  areas,  four  frequency  occurrences  must 
be  estimated.  The  frequency  occurrence  represents,  on  an 
annualized  basis,  how  often  a  threat  agent  can  be  expected 
to  penetrate  the  defenses  of  an  activity  and  successfully 
attack  assets.  This  step  concludes  by  transforming  the 
frequency  occurrence  for  each  impact  area  into  a  frequency 
of  successful  attack  rating  [Ref.  17:  p.  10].  The  model 
component  for  this  sts p  is  summarized  in  Table  III. 

c.   Computation  of  the  Total   Annual  Loss  Expectancy 
(ALE) 

The  final  step  of  the  risk  analysis  calculates 
the  activity's  Total  !\LE  by  a  series  cf  computations.  The 
Total  ALE  quantifies  the  average  yearly  risk  exposure  in 
dollars  resulting  from  modification,  destruction,  disclo- 
sure, or  denial  of  service.  The  activity's  risk  exposure 
reveals  the  degree  to  which  tha  existing  vulnerabilities 
permit  threats  to  be  realized  against  the  assets  of  the  lata 
processing  environment.  The  first  computation  uses  a  matrix 
of  all  assets  and  threats  for  each  impact  area.  An  ale 
(uncapitalized)  is  computed  for  each  combination  of  loss 
rating  (of  a  single  asset)  and  frequency  cf  successful 
attack  rating  (of  a  single  threat)  paired  by  the  same  impact 
area  [Ref.  17:  p.  10].  This  ale  is  the  risk  exposure  for 
that  specific  asset  and  threat  intersection.  The  second 
computation  computes  the  ALE  foe  impact  area  i  as  the  sum  of 
all  ale's  in  impact  area  i.  The  last  computation  totals  the 
four  impact  area  ALEs  .  The  ino3el  component  for  this  last 
step  is  presented  in  Table  IV. 
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TABLE  III 
Threat  and  Vulnerability  Evaluation  Model 

The  freauency  occurrence  function,  F(i,T)r  is 
a  stochastic  estimate  of  the  frequency  per  year 
of  successful  attack  by  threat  T  in  impact  area  i. 

The  function  is  expressed  is: 

F(i,T)  =  function  [D(T),  V(T),  C  (T)  ] 

Where: 

i    =  the  threat  impact  area   (modification,  des- 
truction, disclosure,  or  denial  of  service) 

T     =  the  uniquely  named  threat 

D  (T)  =  the  definition   of  threat  T   aid  listing  of 
of  specific  threat  agents 

V  (T)  =  the  discission  of  tae  vulnerabilities  which 
allow  threat  T  to  materialize 

C  (T)  =  the  description  of  :he  existing  countermea- 
sures  to  oounter  threat  T 

The  frequency  of  successful  attack,  rating  is  a 
mathematical  maoping  from  F(i,T)  onto  an  ordinal 
integer  scale  iranaing  from  0  to  3.  The  zero 
rating  indicates  "Hat  threat  T  dees  not  affect  anv 
of  the  activity's  assets  in  a  particular  impact 
area  i.  After  the  ratiag  is  computed,'  it  is 
rounded  to  the  nearest  integer. 
The  function  is  expressed  as: 

ATTACK  (i,T)  =  log   [3000  x  F(i,T)],  rounded 


2-   Imp_  le  mentation  Considerations 

Top  management  begins  this  phase  by  selecting  the 
risk  analysis  team  aid  providing  them  policy  guidance  on  the 
scope  and  depth  of  the  risk  analysis.  The  members  are 
assigned  in  writing  and  their  accompanying  duties  and 
responsibilities  are  documented.  Team  selection  is  based 
not  only   on  individual   diversity  of   specialized  technical 
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TABLE  IV 
Activity  Total  &LE  Computation 


The  individual  "ale"  function  is  a  ma -a statical 
mapping  from  L035  (i,A)  and  ATTACK  (ifI)  onto  the 
the  annual  loss  expectancy,  in  dollars,  associated 
with  each  combination  of  asset  A  ana  threat  T, 
having  the  same  impart  area,  i. 
The  function  is  expressed  is: 

ale(i,A,T)  = 

1/3  *   10  exp  *LOSS(i,A)  +  ATTACK(i,T)  -  3] 

The    A.  L  E  function,    bv      imnaot      area    i    is    a    summation 
of   the    "aie"s      co rnputed" aoD ve    and   is    expressed    as: 


I      )         ale(i,A,T)       ! 

v  a       vt 


The    activitv      Total    ME   function    is   a    total    of   the 
four    impact'area.    ALEs    and    is    expressed    as: 


Activity    Total    ME   =    /. ,  M«E  (i) 

Vi 


talents,  but  also  oa  familarity  with  the  activity's  mission 
and   knowledge    of  the   data    processing    services    provided. 

The    scope   and    depth    of      the    risk    analysis    depends   on 
the      complexity    of      the   data      processing    environment.  The 

SPLICE  Network,  as  previously  described  in  Section  I.e., 
will  be  a  decentralized,  interactive,  telecommunications 
environment.  Risk  increases  in  direct  proportion  to  the 
complexity  of  the  data  processing  environment.  The  SPLICE 
falls    on      the    high    end      of    the      complexity    scale    as      seen   if 
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Figure  1.1.  It  is  because  of  this  potentially  larce  risk 
exposure  that  the  policy  guidance  concerning  the  risk 
analysis  should  at  the  least  address  the  following. 

The  risk  analysis  conducted  during  the  developmental 
phase  of  SPLICE  will  be  different  from  the  analysis 
conducted  after  the  system  is  operational.  The  risk  in  the 
developmental  phase  is  quantified  either  by  simulating  the 
operational  environment  oc  by  comparing  the  eventual  opera- 
tion to  one  already  in  existence.  The  analysis  of  the 
developmental  phase  daais  with  educated  estimates  and  design 
tiire  considerations*  while  the  i  n^l  vsis  of  the  operational 
system  deals  with  concrete  data  and  mission-essen tial 
requirements.  Since  a  risk  anilysis  is  required  early  in  a 
system's  life  cycle,  hardware  and  software  counter measures 
can.be  included  in  the  final  specifications  and  implemented 
at  a  reasonable  cost.  If  the  risk  is  not  evaluated  until 
the  operational  stage,  many  technically  feasible  counter  mea- 
sures are  nc  longer  practicable  and  less  effective  control 
measures  are  used  to  lanage  the  risk. 

As  stated  earler,  a  risk  analysis  is  reinitiated 
either  after  five  years  or  whenever  the  data  processing 
environment  has  been  affected  by  a  significant  change.  Due 
to  this  recurring  cycle,  policy  guidance  is  needed  on  the 
applicability  of  a  previous  rislc  analysis.  Host  of  industry 
agrees  that  if  five  years  has  passed,  then  the  risk  should 
be  thoroughly  reexaaiaed  and  documented.  Dn  the  other  hand, 
if  only  one  area  has  realized  i  major  change  and  less  than 
five  years  has  passed,  then  only  that  portion  of  the  envi- 
ronment should  be  reevaluated.  During  the  reevaluat ion,  the 
risk  analysis  team  is  cautioned  not  to  overlook  those  areas 
indirectly  impacted  by  the  change. 

The  final  area  requiring  policy  guidance  concerns 
the  level  of  detail  required  to  document  the  estimated  loss 
expectancies  and   frequency  occurrences.     The   degree   of 
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granularity  impose!  by  top  management  directiy  correlates  to 
the  time  and  resources  required  to  conduct  an  activity  risk 
analysis.  The  level  of  detail  should  be  sufficient  enough 
for    the  risk  analysis    to   be    judged   credible    and    defensible. 

Having  discassed  the  policy  areas  requiring  the 
attention  of  top  management,  it  is  now  tine  to  focus  on  the 
practical  considerations  of  actually  conducting  a  risk 
analysis.  The  guidelines  proviied  in  the  next  two  sections 
are  general  rules  of  thumb  synoosized  from  Befs.  10,  33,  20, 
and  21.  Ref.  10,  Appendix  E  contains  the  forms  required  by 
the    DON   for   documenting   an    activity's    risk   analysis. 

a.      Asset  Identification    and   Loss    Expectancy 

Assets  which  function  as  a  single  unit  or  appli- 
cation are  identified  as  a  whole  asset,  since  all  of  its 
components  must  be  working  foe  the  asset  to  be  serviceable. 
Likewise,  if  any  component  is  damaged,  the  entire  asset 
should  be  equally  as  likely  to  saffer  the  same  damage  as  the 
component.  Asset  identification  proceeds  by  reviewing  the 
bread  resource  categories  listed  in  Table  V  and  by  ailing 
additional    assets      that    are      unique    to      the    activity.  The 

current    DON    guidance   states: 


For    each      asset   defined,       all      component 
should   be    in      the    same   phyiscal    area. 
same   manner,       and    subject    to    damage    by    t 

consider   six      identical   c 
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all    of   them.         Dn    the   ot 
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For  example, 
separate  assets 
imply  damage  to 
treat  a  single 
because  if  one 
entire   computer 


[Ref.  10:  p.  E-2] 
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The  level  of  disaggregation  and  the  method  for 
determining  the  loss  associated  with  each  asset  are  two 
areas  which  must  be  standardized  to  minimize  individual 
interpretations  and  double  counting  of  losses.   Some  general 
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TABLE  7 
Asset  Examples  Identified  by  Resource  Category 


Categories 


The  S^iren  Categories  of  Assets 
Representative  Samp_linc[ 


Information 

Syst 
pern" 
(mis 
file 

Hardware 

Cent 
(dis 

•  t  er  f 
daci 
(pri 

Software 

Syst 
a  ail 
ani 

Communica 

tion 

Tele 
esso 

Personnel 

COflD 

buil 
(aiid 

libr 

Adntinistr 

ati  ve 

Docu 

Physical 

Envi 
eqai 

em  (audit 
or ma nee  st 

ter 


trails,  bootstrap  files, 
atistics) ,  application 
transaction  data,  outpu 
s) ,  and  backup  copies 


iles. 


ral  proces 
k  packs,  t 
ace  eauiDn 
base  iaoni 
nter,  :?n 

em  (operat 

t  routines 
backup  cod 

phone  circ 
rs,  mods  a  3 

uter  (ODer 
ding  (jani 
iters,  393 
arian) ,  ma 


sing  system,  storage  media 
apes,  cards),  special  in- 
ent  (f ront-end-brocessor s, 
p.esi  ,  and  I/O  devices 
inals,  disk  drives) 

ing  system,  compilers, 
[f    apolication  programs, 

i  e  s 

uits,  communication  Droe- 
,  and  multiplexors 

ators,  programmers), 
tors,  guards) ,  support 
retarial,  management, 
intenance,  and  users 

mentation,  operational  procedures,, 
guides,  I/O  procedures  and  records 


ronmental 

pment,  3a? 


Systems,  buildings,  offi 
plies  and  auxiliary  powe 


guidelines  on   the  appropriate  level  of   disaggregation  that 
can  serve  as  standards  are  as  follows. 

•  All  information  required  to  perform  i  single  function 
should  be  grouped  accordingly  at  that  functional  level. 
This  is  because  only  partial  information  is  net  suffi- 
cient for  performing  the  application.  For  example,  the 
master  and  transaction  files  of  a  payroll  system  must 
both  be  available  to  issue  paychecks.  This  same 
reasoning  applies  to  the  other  soft  asset   categories  cf 
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software  and  administrative  locuments  and  procedures*  An 
operating  systen  us  many  conponents  such  as  a  job  sched- 
uler, main  memory  manager,  I/O  supervisor,  and  ethers, 
which  must  all  be  operable  to  perform  the  task  of 
managing  the  overall  system.  To  consider  each  component 
as  a  separate  asset  would  be  incorrect  because  thay  all 
act  as  a  single  unit. 

•  The  unique  identification  of  fixed  assets  is  somewhat 
easier  as  their  physical  boundaries  are  visually  recogni- 
zable. Fixed  asssts  includs  the  categories  of  hardware, 
communication,  and  physical  assets  of  an  activity,  and 
are  usually  controlled  by  aerial  numbers  and  custody 
cards.  As  with  soft  assets,  fixed  assets  are  grouped 
according  to  whether  "hey  act  as  a  single  unit.  For 
example,  the  operator  consols  of  a  conputer  system  must 
'be  functioning,  otherwise  the  computer  system  is  inoper- 
able. On  the  other  hand,  if  one  tape  drive  in  an 
inventory  of  six  starts  to  nalfunction,  only  that  tape 
drive  is  affected,  not  all  o£  them. 

•  For  the  remaining  asset  category  of  personnel,  no 
universal  grouping  method  exists.  Each  activity  must 
decide  based  apoi  their  particular  situation  which 
grouping  alternative  is  best.  Some  potential  alterna- 
tives are  by  skills,  experience,  salary,  department 
assigned,  or  job  ol assi ficati on. 

Determining  the  Loss  of  an  asset  requires 
careful  attention  to  how  essential  it  is  in  supporting  the 
mission  and  how  much  an  activity  will  lose  if  it  is  damaged. 
The  user  expresses  how  essential  an  asset  is  by  assigning  it 
a  criticali ty  value  that  reflects  the  importance  given'  to 
the  utilization  of  that  asset.  As  expected,  it  is  not  an 
easy  decision,  and  once  made  should  be  reviewed  and  approved 
by  all  levels  of  management  relying  on  that  asset. 
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For  fixed  assets,  bhe  loss  value  for  modifica- 
tion and  destruction  damage  is  determined  by  the  repair 
cost,  original  cost,  ::  raplacensnt  cost.  Addit  icr.aiiy  for 
destruction,  the  loss  value  Includes  the  cost  of  doing 
without  that  asset.  For  disclosure  damage,  the  user  quanti- 
fies the  loss  by  determining  the  worth  of  the  asset  to 
someone  else,  such  as  a  hostile  agent  (any  unauthorized 
user).  The  remaining  area  of  denial  of  service  is  much 
harder  to  quantify.  One  must  envision  a  ty_pical  timeframe 
during  which  the  asset  would  be  unavailable  to  satisfy  the 
user's  demand  for  processing  and  estimate  the  maximum  time 
period  that  is  tolerable  for  the  user  to  be  without  the 
service  of  that  asset.  Then,  using  these  two  timeframes, 
one  determines  the  estimated  cost  of  getting  that  service 
from  a  commerical  timesharing  company,  realizing  that  the 
user  with  the  shortest  tolerable  time  period  has  the  most 
critical  need  for  service. 

The  soft  assets  of  information,  software,  and 
administrative  documeits  and  procedures  are  subject  to  the 
same  four  areas  of  damage  (modification,  destruction, 
disclosure,  and  deiial  of  service)  as  fixed  assets. 
However,  in  determining  their  loss  values  for  modification 
and  destruction,  a  different  approach  is  taken.  Some  soft 
assets  of  an  activity  are  generated  by  an  internal  project 
team  or  created  uniquely  for  a  particular  function  of  the 
activity.  This  means  that  if  such  an  asset  is  destroyed, 
the  loss  value  is  estimated  by  the  cost  of  recreating  the 
asset  and  of  doing  without  it.  For  modification  damage,  the 
loss  value  is  determined  by  either  revalidating  all  the 
files  or  recertifying  the  administrative  documents  and 
procedures.  To  quantify  the  damage  resulting  from  disclo- 
sure or  denial  of  service,  the  guidelines  given  for  fixed 
assets  are  appropriate. 
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The  issue  of  quantifying  ths  loss  value  of 
assets  for  which  thece  are  replacement  spaces  or  duplicate 
copies  needs  clarif ication .  If  a  terminal  is  destroyed  for 
which  there  is  a  space,  then  the  loss  due  to  destruction  is 
only  the  terminal's  ceplacement  and  installation  cost  and 
does  not  include  the  cost  of  not  having  the  service  avail- 
able. If  no  spare  is  avaiLable,  then  the  loss  from 
destruction  includes  all  three  oosts.  Likewise,  some  soft 
assets,  such  as  centrally  designed  software  or  off-the-shelf 
documentation,  are  easily  replaced  from  another  activity  or 
commerical  vendor.  For  example,  if  an  application  system 
for  which  there  is  a  duplicate  copy  is  modified  or 
destroyed,  then  the  loss  value  only  includes  the  overhead 
and  computer  running  time  neeiei  to  install  the  backup.  The 
point  is  that  the  Idss  value  of  assets  foe  which  there  are 
replacements  must  onLy  ceflect  the  cost  to  install  the 
backup  and  replace  it.  That  oost  might  include  the  addi- 
tional costs  tc  being  the  backup  version  into  operational 
use. 

When  quantifying  tie  loss  value  of  personnel, 
one  takes  into  consideration  the  availability  of  qualified 
personnel,  whether  unique  training  or  knowledge  is  required, 
and  the  activity's  ability  to  absorb  the  loss  based  on  the 
current  number  of  skilled  personnel. 

In  summacy,  the  importance  of  this  step  cannot 
be  overemphasized  since  the  lata  collected  dramatically 
affects  the  analysis.  The  implementation  considerations 
presented  should  be  viewed  a5  a  baseline  for  the  risk 
analysis  team.  Many  additional  constraints  and  guidelines 
are  unique  to  each  particulac  activity  and  must  be  identi- 
fied and  documented. 


48 


b.   Threat  ani  Vulnerability  Evaluation 

In  the  previous  section,  guidance  was  given  on 
quantifying  the  loss  expectancy  of  assets.  This  section 
addresses  the  opposite  siie  of  that  task:  how  an  activity 
identifies  the  potential  problems  and  hazards  of  running  a 
data  processing  environment. 

The  risk  analysis  team  begins  by  marking  those 
assets  critical  to  the  activity* s  mission  and  adding  those 
additional  ones  which  might  be  very  attractive  to  someone 
external  to  the  activity.  Someone  may  want  the  asset 
because  of  what  couii  oe  gainel  by  corrupting  its  internal 
contends,  learning  its  function  or  meaning,  or  denying  the 
activity  possession. 

With  the  assets  just  marked  in  mind,  the  team 
th'en  considers  all  the  potental  threats  that,  if  realized, 
could  inflict  damage.  One  starts  by  considering  the 
possible  adversaries  that  wouli  take  advantage  cf  any  oppor- 
tunity to  attack  tie  activity.  Basically,  this  means 
listing  the  most  likely  threat  agents  (natural  environmental 
factors,  authorized  jsers,  ani  hostile  agents)  and  specu- 
lating on  how  they  could  aurt  ths  activity. 

To  complete  this  review,  it  is  prudent  to  ask 
where  might  each  attack  occur,  such  as  at  the  computer  main- 
frame, remote  terminal,  programming  office,  or  tape  library. 
Additionally,  one  should  ask  when  might  it  happen:  during 
normal  working  hours,  on  holidays,  just  after  a  shift 
change,  or  during  an  emergency  such  as  a  system  crash,  power 
failure,  or  fire.  3y  doing  this  additional  review,  poten- 
tial threat  scenarios  can  be  documented  and  evaluated. 

Having  listed  every  plausible  threat  scenario, 
the  team  determines  how  the  potential  attacks  could  harm  the 
activity.  This  refers  back  to  the  four  treat  impact  areas 
of  modification,    destructon,   disclosure,    and  denial   of 
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service.  In  addition  to  determining  the  impact  area,  ar. 
evaluation  is  mads  ooncerning  i3»  often  a  threat  might  be 
perpetrated.  This  evaluation  i:cour.is  for  the  probability 
of  each  scenario  occurring,  given  the  existing  ADP  security 
posture  of  the  activity. 

In  summary,  one  identifies  threats  by  consid- 
ering those  threats  that: 

•  have  been  known  to  o:cur  at  the  activity  in  the  past: 
machine  failure,  theft,  systsm  crashes,  information  loss 
and  vandalism; 

•  might  occur  witti  sens  reasonable  probability  in  the 
geographic  area:  fire,  earthquake,  and  flood;  and 

•  could  result  froa  aocidsnt al  or  intantial  errors  of 
humans.   [Ref.  22:  p.  32] 

As  a  starting  point,  some  threats  which  are 
common  to  the  current  data  prorsssing  environment  have  been 
listed  in  Table  VI.  Additionally,  the  impact  area(s)  asso- 
ciated with  the  realization  of  sach  threat  is  (are)  marked 
accordingly.  The  samples  are  a  representative  sampling 
which  the  risk  analysis  team  oan  use  as  a  checklist  of 
potential  threat  areas.  For  a  itore  exhaustive  threat  evalu- 
ation the  reader  is  sneouragsd  to  read  Martin  (1973),  N3S 
FIPS  31  (1974),  Ref.  20,  and  Rsf  22. 
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B.       MANAGEMENT    DECISION 

In  this  phase  of  the  Risk  Management  Program,  activity 
top  management  judges  whsther  the  level  of  risk  attributed 
to   the   data   processing    environment   is  acceptable. 

Before  making  that  judgement,  top  management  appraises 
the  risk  analysis.  This  appraisal  includes  conducting  a 
sensitivity  analysis  on  the  data  used  to  substantiate  the 
Total  ALE  and  evaluating  the  technical  merits  of  the  overall 
analysis  effort.  The  sensitivity  analysis  determines  what 
effects  changes  in  the  estimated  data  can  have  on  the  Total 
ALE.  The  technical  merits  can  be  evaluated  by  asking  the 
following    types   of    questions. 

•  Did   the    users      participate    is    estimating    the      loss   expec- 
tancy  of   assets? 

•  Was   the    risk    analysis   team    adequately    skilled   and    experi- 
enced  to    make   the    appropriate    assumptions? 

•  Are   the    results   realistic    and    defensible? 

•  Can   the    results    be    replicated    by   another    team? 

•  Were  the   calculations   perforied   correctly? 

•  Were   the    existing    count ermeasires    sufficiently    considered 
in   the   analysis? 

•  Did   the    risk    analysis    team    adequately    consider    the    activ- 
ity's  mission   and   users'    dependence    on    automated   support? 

If  the  results  of  the  risk  analysis  are  not  acceptable, 
top  management  identifies  the  deficiencies  in  the  analysis 
and  reinitiates  the  Risk  Analysis  Phase.  If  the  results  are 
acceptable,    top    management    approves    the   risk    analysis. 

After  the  risk  analysis  is  approved,  top  management 
determines  whether  all  mandatory  counterneasures  have  been 
implemented.  This  is  done  by  comparing  the  list  of  manda- 
tory count ermeasures  with  th=  existing  ones  documented 
during   step   2    of    the    risk    analysis. 
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Top  management  n:xt  evaluates  the  Total  ALE.  The  deci- 
sion of  whether  ttia  Total  ME  is  acceptable  depends 
exclusively  on  the  amount  of  risk  that  top  management  is 
willing  to  assume,  given  the  activity's  mission  and  users1 
dependence  on  automated  support.  Many  judge  the  level  of 
risk  as  acceptable  when  the  loss  per  year  is  so  small  that 
the  activity*s  overall  mission  is  not  significantly  degraded 
if  threats  are  realizad.  Sines  each  activity  has  a  unique 
combination  of  assets,  vulnerabilities,  personnel,  and 
security  policies  that  establishes  its  data  processing  envi- 
ronment, no  universally  accepted  ALE  is  appropriate  for  all 
activities.      [ Ref •    23:    p.    2 ] 

The  pertinent  decisions  relative  to  this  phase  are 
modeled   by    the      decision   tabia    in    Table    VII.  The    table   is 

divided  intc  two  block s  (conditions  and  actions).  The  deci- 
sion table  is  read  by  IF  condition  1  AND  condition  2  AND 
condition  3  are  trua,  THEN  tats  the  action  marked.  When 
evaluating  each  condition  listed,  note  that  the  column 
entries  indicate  the  conditional  states  of  satisfied  (T) , 
not  satisfied  (F)  ,  or  has  no  bearing  (-)  .  The  action  block 
lists  each  decision  relevant  to  the  various  conditional 
states.  The  action  column  entry  "X"  indicates  the  action  to 
be  taken    while    a   blank    implies    no    action    required. 

C.       RISK    CONTROL 

1.       Model 

The  Risk  Control  Phase  is  concerned  with  selecting 
additional  countermsa suras  to  improve  the  overall  ADP 
security  posture  of  the  activity,  Countermeasures  are 
selected  which  reduce  the  fragiency  cf  particular  threats, 
minimize  the  loss  axpectancy  associated  with  particular 
assets,  or  provide  an  alternative  means  of  automated 
support.     Countermea suras   ara  selected   by   an   iterative 
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TABLE    711 
Management   Decision    Model 
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process,  in  which  steps  2  and  3  of  the  Risk  Analysis  Model 
are  repeated  until  the  projected  Total  ALE  is  reduced  to  an 
acceptable  level.  This  process  is  executed  iteratively  in 
order  to  ensure  that  the  set  of  selected  oounter measure s  is 
the   optimal   set. 

There   are   se/eral   constraints      affecting    the    process 
of        countermeasure        selection.  The        most        significant 

constraint  is  the  required  selection  of  countermeasures 
which  are  designated  mandatory  by  higher  authority  and  must 
be  implemented  regardless  of  any  other  criteria.  Higher 
authority  is  defined  as  the  Designated  Approving  Authority 
and  the   organizational    chain    of    command   in    the    DON. 
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The  second  constraint  is  that  each  countermea sure 
should   provide    a      positive    return    on   investment.  That    is, 

the  reduction  in  Total  ALE  (an  annualized  figure)  as  a 
result  of  the  impleiantation  of  a  countermeasure  must  be 
greater  than  the  annualized  cost  of  the  countermeasure.  The 
ammortized  cost  of  the  countermeasure  is  computed  as  the 
annual  operating  cost  plus  the  annual  portion  of  the  one- 
time costs  associated  with  that  countermeasure.  The  annual 
portion  of  the  one-time  costs  is  the  sum  of  the  development, 
implementation,  and/or  installation  costs,  divided  by  the 
number  of  years  in  the  anticipated  life  of  the 
countermea s ure. 

The  four  stsp  model  of  the  risk  control  phase  is 
presented  in  Table  VIII,  and  described  in  more  detail  in 
Appendix  E  of  Ref.  13.  Step  on=  is  the  examination  of  those 
countermeasures  mandated  by  higher  authority.  Those  coun- 
termeasures  are  placed  at  the  top  of  the  priority  list  for 
implementation.  If  the  projected  Total  ALE  with  the  manda- 
tory countermeasures,  is  less  than  or  equal  to  the  maximum 
acceptable    Total   ALE,     the    Risk    Control   Phase    is    completed. 

If  the  projected  Total  ALE  after  implementation  of 
mandatory  countermeasures  is  still  not  acceptable,  addi- 
tional countermeasures  must  be  selected  for  implementation. 
The  selection  begins  by  finding  the  countermeasure  which  has 
the  greatest  potential  cf  lowering  the  projected  Total  ALE. 
The  process  of  selecting  the  aext  best  countermeasure  is 
repeated  until  the  projected  Total  ALE  is  reduced  to  an 
acceptable  level.  The  process  is  iterative  because  the 
amount  of  reduction  associated  with  each  countermeasure  is 
dependent  on  the  other  countermeasures  previously  evaluated. 
This  anomaly  is  similar  to  the  "law  of  diuinishing  returns" 
when  two  countermeasures  affect  the  same  threat  frequencies 
or   loss  expectancies. 
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TABLE  7III 
Risk  Control  Model 

Objective: 

Choose   C1    through   3  j    so    that 
TALE(E    +    M    +    C1     + +    Cj)     <    MATALE 


By: 


1.  Survey   all    mandatory    sountermeasures. 

If    TALS(E    ♦    M)     <    MAI&LE,    go    to    step    5. 

2.  Choose  countermeasure    C1    such   that: 
TALE  (E   ♦   M    +    C1 )     is    minimized,    and 

TALE  (E    +    M)     -    TALE(    E    +    H    ♦    C1)     >    Cos"  (CI). 

If    TALE(E    ♦     H    C1)     <    MATALE,    go    to    step    5. 

3.  Choose   another   countermeasure,    Cj,    such    that: 
TALE  (E   ♦   M    ♦   C1    ♦  ...«■    Cj)     is    minimized,    and 

TALE  (E    +    3    +    C1     ♦  ...  <•    Ci)     - 

TALE  (E    ♦    M    +    31     +  ...+    Cj)     >    Cost(Cj). 

If    TALE(E    *■     M    *■    C1    ♦ ♦    Cj)     <    3ATALE, 

go   to   step   5. 

4.  Repeat   stap    3   until: 

TALE(E    +    S     +    C1     +  ...♦■    Cj)     <    MATALE. 

5.  Develop   Plan   of    Action    for    implementation    of 
necessary*    countermei sures. 

Where: 

TALE  (E  +  M)  =  Projected  Total  ALE  with  existing 
and  mandatory  countermeasures  (annual) 

MATALE    =   Maximum  acceptable  Total  ALE 

Cost(Cj)  =   Ammcrtized  oost   of   counter  measure  Cj 

TALE(E  ♦  M  +  C1  +  ...♦  Cj)  =  Projected  Total  ALE 
with  existing  coui termeasures,  mandatory 
count ern easures,  and  proposed  countermea- 
sures 1  through  j 

*  Necessary  means  mandatory  and  additional 
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Finally,  the  optimal  set  of  countermeasures  is 
prioritized  and  scheduled  for  implementation.  Top  manage- 
ment is  responsible  for  approving  that  recommended  set  of 
additional        counteme asures        and  their         implementation 

schedule.  Those  considerations  addressing  prioritization 
are    provided  in   the   following   section. 

2«      IroR^lSIltatiori    Considerations 

The  objective  of  the  Risk  Control  Phase  is  to 
provide  an  approvei,  prioritized  optimal  set  of  countermea- 
sures  which,  when  implemented,  lower  the  Total  ALE  of  an 
activity  to  an  acceptable  level.  The  task  is  not  a  simple 
one,  and  requires  that  management  devote  adequate  resources 
in  both  expert  manpower  and  time  to  accomplish  it.  Several 
considerations  must  be  made  during  the  selection  of  counter- 
measures   for  presentation   to    naaagement. 

The  first  consideration,  as  discussed  above,  is  the 
selection  of  those  z ount ermeas ur es  which  are  designated 
mandatory  by  high  authority.  Tie  SPLICE  network  and  indivi- 
dual SPLICE  locations  are  required  to  implement  those 
countermeasure s  listed  in  Appendix  J  of  DPNAVINST  5239. 1A 
[Ref.    10]      and      NAVSUPINSI    5510.  5A      [  Ref .    15].  Additional 

mandatory  countermeasures  may  be  identified  in  future  revi- 
sions of  the  SPLICE  Security  and  Risk  Analysis  Plan 
[Ref,    11]. 

The   second        consideration        concerns  the        cost- 

effectiveness  of  eaca  counter nea sure.  To  be  a  candidate  for 
selection,  a  countermeasure  must  have  a  postive  return  on 
investment.  That  is,  the  benefit  realized  by  implementing 
the  countermeasure  must  be  greater  than  the  ammortized  cost 
of   the   countermeasure. 

The  final  consideration  in  compiling  a  set  of  candi- 
date countermeasures  concerns  the  feasibility  of  each 
countermeasure.  Those      countermeasures        which      the      risk 
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control  team  judges  ir.feasible  due  to  such  things  as 
geographic  location  or  technical  limitations  should  be  docu- 
mented as  "considered ,  but  judged  infesible."  Thorough 
documentation  and  naaagemant  participation  is  crucial  during 
this  feasibility  review  to  adequately  address  activity 
budgetary  constraints.  For  those  countermeasures  judged 
feasible  and  practical,  top  management  initiates  the  appro- 
priate planning  and  budgeting  support  needed  for  their 
implementat  ion. 

To  ensure  that  the  optirai  sex.  of  countermeasure  s  is 
proposed,  the  risk  control  tean  analyzes  the  results  of  the 
risk      analysis    froii      several    perspectives.  The    matrix      of 

assets  and  threats  is  exarainel  to  identify  those  threats 
with  the  greatest  potential  for  harm,  in  terms  of  their 
threat      frequencies.  Specific    countermeasures      should      be 

considered  which  reiice  the  likelihood  of  those  threats 
occurring. 

Additionally,  the  team  reviews  the  matrix  to  iden- 
tify those  assets  with  high  loss  expectancies.  It  is 
important  to  recall  at  this  point  that  the  loss  associated 
with  an  asset  is  not  limited  to  the  replacement  value  of 
that  asset,  but  is  often  compounded  with  the  value  of  the 
service  that  the  asset  proviies.  Those  countermeasures 
which  minimize  the  loss  expectancies  associated  with  assets 
should   be   considered    for   i mplenentation. 

Finally,  a  global  inspection  of  the  risk  analysis 
must      be   taken.  During   this      inspection,      top      management 

relies  on  the  technical  expertise  of  the  risk  control  team 
to  "read  between  the  lines"  of  the  asset/threat  matrix  and 
to  identify  those  vulnerabilities  that  allow  a  variety  of 
threats  to  materialize.  The  forms  required  for  the  evalua- 
tion  of   countermeasures   are   provided    in   Ref.     10. 
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As  explained  in  the  Risk  Control  Model,  proposed 
countermeasures  are  selected  in  an  iterative  process. 
Countermeasures  are  normally  targeted  to  reduce  the  vulner- 
abilities of  an  activity  and,  when  implemented,  usually 
affect  multiple  vulnerabilities  simultaneously.  Due  to  this 
overlapping  result,  the  effectiveness  of  a  countermeasure 
must  be  evaluated  witti  respect  to  the  entire  data  processing 
environment  before  determining  the  total  benefit  that  could 
be  realized.  Additionally,  the  implementation  of  a  counter- 
measure  could  in  sone  situations  generate  a  more  serious 
vulnerability  than  that  whioh  the  countermeasure  was 
intended      to  correct.  In      this      situation,      activity      top 

management  must  decile  if  the  benefit  gained  outweighs  the 
weakness  created.  For  example,  a  recommended  software  coun- 
termeasure might  reguire  multiple,  lengthy  passwords  to 
improve  access  control.  Unfortunately,  passwords  of  this 
nature  are  often  written  down  and  taped  to  terminals, 
thereby  negating  the  effectiveness  of  passwords  and  creating 
a  greater   vulnerability. 

When  the  projected  Total  ALE  with  the  additional 
countermeasures  considered  is  less  than  the  maximum  Total 
ALE      acceptable,  the     selection      of        countermeasures      is 

completed.  The  next  task  of  the  risk  control  team  is  to 
develop  a  plan  of  action  for  implementing  the  set  of 
selected  countermeasures.  The  development  of  this  plan  will 
be  guided  by  the  availability  and  timing  of  those  resources 
reguired  for  countermeasure  implementation.  When  the  set  of 
proposed  countermeasures  and  the  implementation  plan  is 
approved  by  top  management,  the  Risk  Control  Phase  is 
completed. 

Recent  ADP  security  literature  provides  documenta- 
tion on  a  variety  of  countermeasures.  A  discussion  of  many 
of  those   countermeasures  is    provided    in   the    next    chapter. 
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D.       OPERATIONAL    CONTINUITY 
1.       Model 

Like  the  Management  Decision  Phase,  the  Operational 
Continuity  Phase  is  modeled  by  a  decision  table.  The  table 
is  applicable  at  any  time  during  the  phase,  which  can  be  as 
long  as  five  years.  Since  the  Risk  Management  Program 
requires  continual  rsview  of  the  ADP  security  posture  of  the 
activity,  the  decision  table  should  be  consulted  on  a 
continual   basis. 

Some  elements  of  the  decision  table,  which  is  given 
in  Table  IX,  deserve  a  rnplif  ication .  When  an  activity  enters 
the  Operational  Continuity  Phas=,  a  request  for  accredita- 
tion is  immediately  forwarded  tD  the  DAA.  If  the  activity 
has  no  countermeasures  which  must  implemented,  this  initial 
request  can  also  be  considered  a  final  request.  If  neces- 
sary countermeasures  are  to  be  implemented,  then  a  final 
accreditation  request  will  be  sibmitted  when  their  implemen- 
tation  is   completed. 

According  to  Ref-  13,  an  activity  must  conduct  a 
risk  analysis  and  be  accredited  every  five  years  or  whenever 
there  is  a  significant  change  in  the  system  configuration  or 
facility.  Therefore,  a  "Not  satisfied"  (F)  in  either  of 
these  conditions  regnires  initiation  of  the  Pisk  Analysis 
Phase,  regardless  of  any  other  conditions.  Finally,  since 
the  Operational  Continuity  Phase  can  be  entered  from  either 
the  Management  Decision  Phase  or  the  Risk  Control  Phase,  a 
likelihood  exists  that  the  imols n enration  of  countermeasures 
is  happening  simultaneously  witi  the  daily  operation  of  the 
activity.  The  responsibilities  and  authorizations  needed  to 
implement  the  necessary  counternea sures  is  addressed  in  the 
Implementation  Considerations.  When  the  Plan  of  Action  for 
implementing  the  necessary  countermeasures  is  completed,  a 
request   for    final   accreditation    is    submitted    to    the   DAA. 
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TABLE    IX 
Operational   Continuity    Decision    flodel 
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2«   Imp lementatioa  Considerations 

When  this  phase  is  entered,  activity  top  management 
has  approved  the  results  of  the  Risk  Analysis  Phase,  and,  if 
the  Risk  Control  Phase  was  execited,  has  approved  a  list  of 
necessary  countermeas ures  and  their  implementation  plan. 
This  review  and   approval  docja=n t ation  is  submitted   to  the 
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DAA  in  support  of  an  initial  request  for  accreditation. 
Opon  receipt  of  the  request,  the  DAA  will  issue  an  activity 
accreditation  that  assigns  each  ADP  system  of  the  activity 
to  one  of  the  following  three  categories: 

•  ADP  systems  for  which  all  cost-ef  fective  counter  measures 
have  been  implemented, 

•  ADP  systems  with  an  acceptable  projected  level  of  risk, 
but  with  some  count ermeasurss  not  yet  implemented  (these 
systems  will  be  granted  an  interim  authority  to  operate 
pending  implementation  completion),  and 

•  ADP  systems  with  a  unacceptable  level  of  risk,  which 
requires  that  operations  cease  until  corrective  measures 
have  been  implemented.   [Ref.  10:  pp  3-2,  3-3] 

As  previously  stated,  the  Operational  Continuity 
Phase  includes  implementing  tie  countermeasures  approved 
during  the  Risk  Control  Phase  (if  any)  and  conducting  an 
ongoing  audit  and  security  inspection  of  the  activity  ADP 
security  posture.  Dne  individual  must,  be  assigned  these 
responsibilities  and  given  appropriate  authority  and 
resources  to  execute  them.  That  person  is  designated  the 
Activity  ADP  Security  Officer  and  is  the  head  of  the  ADP 
Security  Staff.  The  responsibilities  of  both  the  ADP 
Security  Officer  and  the  staff  are  presented  in  detail  in 
Chapter  2  of  Ref.  10. 

During  the  implementation  of  necessary  countermea- 
sures,  the  Plan  of  Action  may  require  adjustments.  To  allow 
for  this,  there  must  be  a  responsive  two-way  communication 
between  the  ADP  Security  Officer  and  top  management  about 
real  world  considerations  and  constraints.  Some  reasons  for 
modification  might  be  unforeseen  budgetary  changes  cr 
required  implementation  of  a  as*  directed  mandatory  counter- 
measure.  Additionally,  the  plan  shoull  be  "tweaked"  to 
minimize  the  disruption  of  daily  operations. 
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When  all  necessary  count ermeasures  have  been  imple- 
mented and  a  reguest  for  final  accreditation  has  been 
submitted,  the  DAA  evaluates  the  effectiveness  of  the  new 
countermea sures  by  means  of  a  Security  Test  and  Evaluation 
(ST5E)  [Ref.  10:  p.  3-6].  After  the  STSE,  the  DAA  responds 
to  the  accreditation  request  by  assigning  each  ADP  systems 
to   one  of    the    three    categories    liscussed   above. 

The  Operational  Continuity  Phase  is  terminated  when 
policy  dictates  that  another  risk  analysis  is  required.  At 
a  minimum,  the  Risk  Analysis  P^iase  will  be  r eir.itiated  when 
in  the  opinion  of  tap  manageneit  there  has  been  a  signifi- 
cant change  to  the  configuration  (hardware  or  software)  or 
facility,  or  when  there  has  beei  a  lapse  of  five  years  since 
the   last   approved  risk   analysis. 
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IV.  TECHNICAL  AND  MANAGERIAL  COUNTERMEASORES 

As  stated  previously,  the  current  data  processing  envi- 
ronment is  viewed  as  a  collection  of  assets.  To  protect 
these  assets,  various  technical  and  managerial  security 
mechanisms  are  implenented.  Technical  countermeasures  are 
those  internal  hardware,  software,  and  communication  projec- 
tion mechanisms  that  are  peculiar  to  the  &DP  system  and  are 
best  addressed  in  the  overall  system  design  specifications. 
Managerial,  also  called  conventional,  countermeasures  are 
these  administrative,  personnel,  and  physical  mechanisms 
that  are  commonly  required  for  the  protection  of  any  envi- 
ronment, automated  or  not.  Managerial  countermeasures  are 
implemented  throughout  the  system's  life  cycle  and  are  often 
used  to  enhance  the  effectiveness  of  technical 
countermea  sures . 

The  ADP  security  policies  which  industry  enforces 
through  the  implementation  of  technical  anl  managerial  coun- 
termeasures are: 

•  all  users  and  devices  requira  positive  unique  identifica- 
tion and  verification  (authentication). 

•  all  interactions  involving  asers,  de/ices,  and  other 
named  system  elements  will  be  controlled  by  an  authoriza- 
tion strategy  (access  control)  . 

•  all  activity  within  the  AD?  system  should  be  observed  so 
that  users  (authorized  or  not)  can  be  detected  and  held 
accountable  for  their  actions  (surveillance). 

•  all  elements  of  the  ADP  system  will  function  in  a  cohe- 
sive, identifiable,  predictable,  and  reliable  manner  so 
that  malfunctions  are  detected  and  reported  within  a 
known  time  (integrity). 
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The  countermeasuira  s  discussed  in  this  chapter  are  organ- 
ized by  the  four  ADP  security  policies  presented  above.  The 
countermeas ures  are  iDt  identified  specifically  as  technical 
or  managerial  because  a  combination  of  both  is  required  to 
enforce  an  adequate  P. DP  security  policy.  For  example,  the 
authentication  policy  is  often  achieved  by  implementing 
passwords.  For  passwords  to  be  effective,  they  require  a 
software  mechanism  to  accept  ani  recognize  passwords  and  an 
administrative  control  to  properly  distribute  and  audit 
their  usage. 

A.   AUTHENTICATION 

Authentication  counte rmeasures  prohibit  the  use  of 
system  resources  by  unauthorized  users  cr  devices  by 
verifying  the  unique  identity  of  the  user  or  device  before 
servicing  a  request. 

1-   U§e_I  Authentication 

User  authentication  is  essentially  a  two-step  proce- 
dure of  identity  definition  and  identity  verification.  In 
the  first  step,  the  user  provides  his  or  her  user  identifi- 
cation number  and  password  during  initial  log-on  to  the 
system.  In  the  second  step,  the  system  performs  a  table 
lookup  and  verifies  that  the  password  provided  correctly 
maps  to  the  user  identification  number.  Additionally, 
administrative  controls  ensure  that  each  identification 
number/password  combination  is  assigned  to  only  one  user, 
and  that  the  user  has  not  provided  his  or  her  unique  number 
and  password  combination  to  someone  else. 

User  authentication  can  be  performed  to  some  extent 
at  the  physical  security  level  by  such  controls  as:  guards 
stationed  at  physical  entry  points,  personnel 
sign- in/sign-out   logbooks,    and   closed-circuit   monitors. 


These  physical  security  counter  measures  are  not  sufficient 
at  the  ADP  system  leval,  particularly  if  the  system  supports 
remote  terminals  or  network  communications.  As  an  example, 
when  a  user  submits  a  batch  job  to  the  data  processing 
center  in  person,  his  or  her  identity  can  be  verified.  When 
that  same  batch  job  Is  submitted  from  a  remote  terminal,  the 
user's  identity  is  no  longer  assured. 

There  are  three  methods  for  verifying  a  user's  iden- 
tity. These  methois,  which  can  be  applied  singly  or  in 
combination,  are  basai  on: 

•  something  the  person  knows  (e.g.,  a  password,  a  combina- 
tion to  a  lock,  or  a  fact  about  the  user's  personal 
background)  ; 

•  something  the  parson  has  (a.g.,  a  badge,  a  key  to  a  lock, 
or  a  card  with  machine  readable  information) ;  or 

•  something  the  person  is  (a.g.,  his  or  her  signature, 
speech,  hand  geomatry,  or  fiagerprints)  .  [Ref.  24:  pp. 
8-10] 

Several  comma rcially  developed  devices  for  recog- 
nizing personal  attributes  such  as  fingerprints  or  hand 
geometry  are  available.  However,  the  cost  of  implementing 
such  count ermeasures  make  them  impractical  for  most  decen- 
tralized data  processing  environments  lika  the  SPLICE 
Network.  The  practicality  of  their  implementation  depends 
on  the  cost  of  the  cDuntermeasur e  in  relation  to  the  amount 
of  protection  needea  to  lessen  the  activity's  potential 
losses. 

The  most  widely  accepted  countermeasure  for 
enforcing  an  authentication  policy  is  the  assignment  of  a 
unique  user  identification  numDer  and  password.  The  user 
number  is  entered  via  a  badge  :r  card,  or  entered  from  a 
keyboard,  whereas  the  passworl  is  generally  entered  only 
from  a  keyboard.    la  addition  to  its  use  in  authentication, 
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the  user's  identification  number  is  also  used  in  maintaining 
a  journal  of  his  or  her  activities.  Passwords,  unfortu- 
nately, have  many  potentially  damaging  vulnerabilities. 
Some  technical  and  managerial  countermeasures  that  have  been 
recommended  by  Courtney  [Bef.  3:  pp.  40  -43,  ],  NB3  [Ref.  24: 
pp.  9  -  12],  and  Shaiker  [Ref.  25:  p.  30,]  as  appropriate  to 
counteract  the  vulnerabilities  of  passwords  are  as  follows. 

•  Password  GeneratiDn  and  Selection  -  Passwords  should  be 
comprised  of  a  sufficient  nunber  of  characters  and  gener- 
ated in  such  a  manner  as  to  assure  a  degree  of  protection 
commmensurate  with  the  value  of  the  assets.  They  should 
be  generated  randomly,  so  that  no  association  with  a 
particular  user  oan  be  detected.  Bernan  has  suggested 
that  password  generation  be  based  on  the  concept  of  a 
"virtual  password"  [Ref.  26:  pp.  97-104].  The  password 
is  created  at  the  time  -he  user  identifies  himself  or 
herself  to  the  system  and  is  based  on  the  user's  identi- 
fication number,  social  seourity  number,  and,  in  some 
cases,  the  user's  department  number.  Ref.  26  also 
provides  a  sample  algorithm  that  is  suitable  for  gener- 
ating a  "virtual  password." 

•  Password  Distribution  -  Passwords  for  accessing  the  ADP 
system  should  be  distributed  only  to  users  meeting  the 
ADP  system's  need-to-know  and  need-to- utilize  criteria. 
The  use  cf  a  unique  password  by  a  user  to  access  the  the 
ADP  system,  the  application  system,  and  the  network  is 
endorsed  by  industry  and  is  used  by  several  command  and 
control  ADP  systens  within  the  Navy.  This  hierarchy  of 
access  requires  that  the  urer  be  authenticated  at  the 
system,  application,  and  network  levels.  Each  password 
should  be  personally  delivered  to  a  user  with  instruc- 
tions to  memorize  it,  or  it  should  be  transmitted  over  a 
secured  communicat icn  path  tD  the  user.    If  the  password 
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is  transmitted,  then  either  the  user  should  immedia tely 
initiate  a  password  change  or,  if  impls aented,  an  auto- 
matic password  change  routine  should  be  invoked  after 
initial  log- on. 

Password  Storage  Protection  -  Passwords  are  usually 
stored  in  a  file  located  in  nain  memory.  The  file  is 
therefore  vulnerable  to  tampering.  To  protect  the  pass- 
word file,  an  appropriate  countermeasure  is  to  either 
encrypt  the  file  using  the  Data  Encryption  Standard  (see 
Ref.  27)  or  pass  the  file  through  a  hard-to-invert  trans- 
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sufficiently  difficult  to  prevent  a  code  breaker  from 
successfully  breaking  the  code  with  a  reasonable  amount 
of  time  and  resources. 
•  Password  Usage  Protection  -  Passwords  entered  via  CRT  or 
printing  terminals  should  be  prevented  from  display  by 
masking  the  keyboard  response.  Additionally,  a  security 
alarm  or  a  terminal  lookout  should  be  generated  automati- 
cally after  a  specific  nunber  of  unsuccessful  aocess 
attempts  or  a  specific  tine  delay  has  elapsed  since  the 
last  aocess  attempt.  In  order  to  uncover  possible  unau- 
thorized usage  of  a  password,  it  is  suggested  that  each 
user  be  shown  a  record  of  the  most  recent  accesses  under 
his  or  her  password  upon  log-on.  To  protect  passwords 
during  a  communications  transmission,  an  appropriate 
counter measure  is  to  use  either  an  encryption  technique 
or  a  protected  con municat ions  distribution  system 
[Ref.  10:  p.  F-39  ].  The  system  shouli  also  respond  in 
the  same  manner  to  a  valid  identification  number  and 
invalid  password,  as  it  does  to  an  invalid  identification 
number  and  invalid  password.  This  prevents  a  user,  who  is 
attempting  an  unauthorized  izzqss,  to  know  whether  the 
identification  nunber  is  valid  or  not. 
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•  Password  Lifetime  -  Passwords  should  be  changed  periodi- 
cally, since  the  likelihood  oE  them  being  surreptitiously 
discovered  increases  with  tins.  Also,  if  a  password  is 
compromised  or  a  user's  access  right  is  revoked,  then  the 
password  should  be  immediately  invalidated. 

2-   Device  Authentication 

Besides  authsi tica ting  an  authorized  user,  the  ADP 
system  should  be  able  to  uniquely  recognize  devices  that  are 
requesting  services.  This  is  particularly  important  when 
evaluating  the  threats  posed  by  remote  or  portable  termi- 
nals. An  appropriate  technical  countermeasure  is  to  require 
each  device  to  be  equipped  with  circuitry  which  will  respond 
automatically  to  an  interrogation  command  and  transmi-  an 
identification  code.  This  handshaking  between  the  AD? 
system  and  the  remote  device  is  accomplished  either  by  an 
exchange  of  identification  codes  or  by  the  successful  execu- 
tion of  a  particular  algorithm.  The  identification  code, 
also  called  a  security  code,  should  identify  the  particular 
device  and  be  unique  within  the  system.  This  permits  a 
system-wide  journal  to  maintain  a  log  of  accesses  by  device. 
The  device's  circuitry  should  be  protected  in  tamper- 
resistant  housing,  and,  if  the  amount  of  protection 
warrants,  the  transmission  should  be  protected  by  encryption 
or  a  protected  communications  distribution  system. 
[Ref.  24:  p. 22] 

If  the  system  services  devices  which  are  not 
directly  connected,  it  should  be  capable  of  initiating  a 
call-back  procedure  that  verifies  the  device's  identity. 
This  call-back  procedure  makes  use  of  a  remote  access  list, 
which  must  include  device  identification  codes  and  a  set  of 
authorized  logical  addresses  or  telephone  numbers  from  which 
each  device  can  originate  a  request.   Implementing  either  of 
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these  count ermeasures  will  enable  the  ADP  system  to  guard 
against  an  unauthorized  devic=  nasguerading  as  an  authorized 
one. 

B.       ACCESS    CONTROL 

Access  control  co untermeasi res  enable  properly  identi- 
fied users  to  access  only  thosa  system  resources  for  which 
authorization  has  been  granted.  Traditionally,  authoriza- 
tion in  conventional  systems  has  meant  that  every  system 
element  is  automatically  granted  access  to  every  other 
system      element,  unless      specifically        prohibited.  In 

contrast,  ADP  systsms  base  authorization  on  the  "least 
privilege"  principle,  which  states  that  a  system  element  is 
expressly  prohibited  from  accessing  another  element,  unless 
authorization  has  beai  explicitly  granted.  This  principle 
limits  the  damage  that  can  result  from  error  or  malicious 
attack  and  restricts  the  access  of  system  elements  to  a 
protective    domain. 

Before  discussing  the  design  considerations  for  access 
control  mechanisms,  an  explanation  is  reguired  of  what 
constitutes  a  subject  and  an  objsct.  A  subject  is  an  active 
entity  in  the  ADP  system  that  corresponds  to  a  process  or 
task  acting  on  behalf  of  a  user  or  the  operating  system.  An 
object  is  either  a  software  craated  entity  which  represents 
a  collection  of  information  (2.g.,  file,  directory,  or 
program)  or  a  hardware  recognizable  entity  like  a  terminal 
or  special- purpose  register.  An  access  matrix  conceptually 
represents  what  subjects  can  access  what  objects  and  speci- 
fies what  access  rights  (read,  write,  delete,  etc.)  the 
subjects    have    to  the    objects. 
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1 •   Access  Control  Desian  Considerations 

The  design  of  acciss  control  mechanisms  is  based  on 
three  considerations:   [Ref.  28:  pp.  192-217] 

•  Access  Hierarchies,  which  automatically  give  privileged 
subjects  a  superset  of  the  access  rights  of  nonprivil eged 
subjects.  Privileged  subjects  are  those  active  entities 
of  a  two-state  machine  that  operate  in  the  supervisor 
domain.  A  subject  operating  in  this  domain  has  access  to 
all  objects  in  the  system,  car.  create  and  delete  objects, 
initiate  and  terminate  user  processes,  and  execute  privi- 
leged instructions  not  available  to  subjects  operating  in 
the  user  domain  (nonpri vilaged  subjects).  For  example, 
processes  in  the  supervisor  domain  can  change  process 
status  words  and  Bxecute  I/O  instructions,  while  those  in 
the  user  domain  can  only  request  those  services  be 
provided  on  their  behalf. 

•  Authorization  Lists,  which  associate  with  each  object 
those  subjects  which  have  aocess  rights  to  it.  These 
lists  are  typically  used  to  protect  owned  objects  such  as 
files  and  data. 

•  Capabilities,  which  are  like  "tickets"  for  objects; 
possession  of  a  capability  unconditionally  authorizes  the 
holder  access  for  all  associated  objects.  In  other 
words,  associated  with  each  subject  is  a  capabilities 
list  which  specifies  the  sjbject's  access  rights  to  a 
list  of  objects. 

Access  control  can  be  segregated  into  several 
levels:  system,  subsystem,  file,  record,  or  field,  where  the 
subjects  access  rights  are  delineated  at  each  level.  With 
an  access  control  mechanism  designed  to  mediate  accesses 
down  to  the  field  level,  a  greater  likelihood  exists  of 
detecting   a  violation   or    misuse   of   system   resources. 
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However,  such  a  iesign  significantly  increases  the  n amber 
and  types  of  accesses  to  be  verified  and  generally  leads  to 
a  degradation  of  system  performance. 

2-   Access  Control  IHSl^Sillta tion 

Access  control  counter neasures  are  implemented  by 
software  routines  which  execate  in  the  supervisor  domain, 
and  are  invoked  by  the  file  manager  to  grant  or  deny  access 
when  symbolic  references  are  made  between  subjects  and 
objects.  As  shown  in  Figure  4.1,  the  access  control  matrix 
identifies  all  sabjects  and  objects  in  the  system  and 
defines  their  relationship.  If  the  matrix  were  directly 
implemented,  the  tima  reguired  to  validate  an  access  request 
could  be  unreasonable  due  to  ths  potentially  large  number  of 
empty  spaces  in  the  matrix. 

Depending  on  the  system  software  design,  the  access 
control  countermeasur e,  which  enforces  the  relationships 
depicted  in  the  matrix,  can  be  implemented  in  different 
ways.  One  approach  is  to  organize  and  store  the  access 
relationship  from  the  subject's  perspective,  thereby  elimi- 
nating empty  spaces  in  the  matrix.  This  perspective,  which 
is  called  a  capability-list  orientation,  maintains  a  capa- 
bility list  for  each  subject  giving  both  the  subject's 
access  rights  and  its  related  objects.  The  advantage  of 
this  approach  is  that  once  the  subject's  capability  list  is 
retrieved,  the  time  required  to  validate  subsequent  access 
requests  is  minimal.  [Ref.  28:  pp.  207-218,  Ref.  29:  p. 
169] 

A  second  approach  is  to  organize  and  store  the  rela- 
tionship from  the  object's  perspective,  where  once  again  the 
empty  spaces  are  eliminated.  This  perspective,  which  is 
called  an  authorization-list  orientation,  maintains  with 
each  object  a  list  of  authorize!  subjects  and  their  respec- 
tive access  rights.    The  advantage  of  this  approach  is  that 
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Figure  '+  .  1    Access  Control  Matrix. 

once  an  object  has  bsen  requests!,   further  requests  for  the 
same  object  can  be  rsadily  processed.   [Ref.  29:  p.  169] 

Each  of  ths  ipproaches  discussed  above  has  a  serious 
maintenance  problem.  For  example,  when  an  object  is  removed 
or  a  subject's  access  rights  are  changed,  an  exhaustive 
search  is  needed  to  update  all  affected  sntries.  This  is 
very  time  consuming  when  using  a  list  based  strictly  on 
either  capabilities  d:  authorizations.  Rsf.  29  recommends 
an  authority-item  approach  to  overcome  this  deficiency.  The 
approach  is  explained  as  a  method  for 


organizing  the  a:c?ss  control  information  into  authority 
items,  each  of  which  corresponds  to  a  user  (subject). 
Furthermore,  evary  resource  (object)  in  an  authority 
item  is   linked  with   the  saur   resources  (objects)    in 
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other  authority  items.  Tius,  the  authority  item 
approach  supports  capability  lists  directly  and  access 
(authorization)  lists  indirectly  through  linkages.  In 
this  way,  search  of  authority  items  due  to  removal, 
changes.  and  suspensions  need  not  be  exhaustive. 
[Ref.  29:  p.  170] 


Regardless  of  the  approached  pursued,  the  overriding 
consideration  is  to  reduce  the  time  neede3  to  grant  or  deny 
an  access  request  and  to  provide  a  flexible  mechanism  that 
can  readily  adapt  to  the  dynamic  interaction  between 
subjects  and  objects.  For  additional  information  on 
different  implementations  of  access  control  countermeasures, 
the  works  by  Stiegler  (1979),  Buttar  (1930)  and  Gladney 
(1975)  are  recommends!  . 

The  implementation  approaches  presented  above  were 
directed  towards  alternative  design  proposals  for  the  access 
control  function.  These  same  considerations  apply  equally 
as  well  to  the  design  of  a  data  base  management  system  since 
it  also  is  concerns!  with  ensuring  that  only  authorized 
users  gain  access  to  resources  "Ref.  30:  pp.  229-252]. 

C.   SURVEILLANCE 

The  surveillance  countemeasure  detects  and  reacts 
appropriately  to  any  internal  system  activity  that  it  has 
determined  may  constitute  a  security  threat.  In  order  to 
determine  the  source  of  this  threat,  the  system  must  have  a 
means  of  achieving  strict  personal  accountability  for  all 
users  (unique  assignment  of  identification  numbers).  A 
surveillance  countemeasur e  needs  the  capability  to  concur- 
rently perform  two  functions:  threat  monitoring  and 
security  auditing.  For  the  count ermeasure  to  be  effective, 
the  events  to  be  itonitored  aid  legged  must  be  approved 
during  the  design  of  the  ADP  system  and  the  capability 
implemented  prior  to  its  operational  use.  The  surveillance 
countermeasure   is  usually   implemented   to   operate  in   the 
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privileged  domain  and,  like  all  other  system  software, 
requires  protection  from  unauthorized  modification,  destruc- 
tion, disclosure,  or  denial  of  service. 

Threat  monitoring  is  the  real-time  detection  of  a 
successful  or  attempted  penetration  of  the  ADP  system.  The 
threat  monitor  observes  all  user  and  system  interactions  to 
ensure  that  the  proper  actios  and  responses  are  being 
exchanged.  If  the  monitor  detects  a  security  violation 
(penetration  attack),  it  must  record  the  event  and  take  some 
automatic  action,  depending  upon  the  severity  and  effect  of 
the  violation.  This  action  could  range  from  printing  a 
security  alert  message  on  the  operator's  console  to  sounding 
an  alarm  in  the  AOP  Security  Officer's  location.  In 
designing  the  monitor,  one  must  address  what  information,  if 
any,  should  be  returned  to  the  iser  attempting  to  compromise 
the  system  and  what  the  disposition  of  the  user's  program 
should  be  if  execution  had  been  initiated. 

Security  auditing  concerns  the  logging,  analyzing,  and 
reporting  of  security -related  events,  in  particular,  any 
attempted  or  successful  security  violation.  The  logging 
function  collects  and  records  in  a  historical  file  such 
things  as  the  user's  identification  nuitber  and  time  of 
log-on,  the  devices  from  which  the  user  has  entered 
commands,  programs,  and  files,  and  any  other  system  data 
unique  to  the  particular  user  session  (e.g.,  general  regis- 
ters, memory  bounds,  location  of  virtual  memory  table) 
[Ref.  29:  p.  166].  The  logs  are  used  to  provide  an  audit 
trail  of  system  activity  and  to  assist  in  the  investigation 
of  recorded  security  violations. 

Analyzing  and  reporting  of  security-related  events  is  a 
joint  responsibility  of  the  surveillance  software  counter- 
measure  and  the  ADP  Security  Officer.  The  countermeasur e  is 
normally  designed  to  aaintain  statistics  on  security-related 
events  and   to  prepare  standardize   reports  on   such  events. 
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while  it  is  the  ADP  Security  Officer  that  interprets  these 
products  and  takes  appropriate  ictions  to  correct  the  docu- 
mented vulnerabilit ies .  It  is  intended  that  a  surveillance 
countetmeas ure  will  act  as  an  affective  psychological  deter- 
rent to  the  user  who  night  otherwise  consider  abusing  his  or 
her   privileges. 

D.       INTEGRITY 

Integrity  is  the  quality  of  protection  that  assures  that 
the  ADP  system  works  in  a  cohesive  and  predictable  manner 
regardless  cf  the  operating  conditions,  that  technical  coun- 
termeasures  are  effective  ia  maintaining  the  desired 
security  level,  and  that  the  ADP  system  is  adequately 
protected  from  the  occurrence  aid  impact  of  errors  [  Ref .  31: 
pp.         15-17].  Count  ermeasures      for        enforcing      a      system 

integrity  policy  incLide  controls  for  the  internal  (hardware 
and  software)  system,  processing,  and  system  errors.  The 
technical  countermea sures  presented  in  the  following 
sections  have  been  synopsized  from  Refs.  29,  32  and  33.  The 
listing  is  by  no  means  exhaustive,  rather  it  repesen-s 
industry's  judgement  of  the  roost  effective  counter meas ures 
for    today's      hardware    and    software.  These    countermeasures 

are  not  usually  identified  explicitly  as  security  mechan- 
isms, but  are  often  present  for  assuring  a  high  degree  of 
system   reliability. 

1-      Internal   Sy_stem  Controls 

In  today's  mul tiprograaning  and  amltiprocessing  ADP 
systems,  many  users  are  concurrently  sharing  system 
resources  (memory,  C?J,  and  I/O  devices)  and  programs.  The 
multiplexing  of  these  elements  among  many  users  has  created 
a  need  to  isolate  (s elf- protect)  user  programs  from  one 
another,         the      system      software,  and      the      other      system 
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resources.     This   isolation  of    elements   is   achieved   by 

implementing  various  technical  countermeasures  that  provide 

for   main  memory   protection,  lual   execution  states,    and 
virtual  machine  monitors. 

a.   Main  Memory  Protection 

Main  memory  protection  concerns  the  ability  to 
protect  partitions  or  portions  of  main  memory  from  unwar- 
ranted access  by  us=r  programs.  Main  aemory  is  usually 
divided  into  mutually  exclusive  areas  thar  are  managed  by 
the  system  software.  The  systaa  software  loads  these  areas 
with  as  many  user  programs  as  oan  be  efficiently  serviced. 
In  previous  generations,  this  meant  bringing  in  a  user 
program,  executing  it  for  a  period  of  time,  suspending  its 
execution,  and  loading  in  anothsr  user  program.  This  swap- 
ping continued  usually  via  a  round  robin  servicing  scheme 
until  the  user  program  had  finished  execution.  This  is  no 
longer  judged  as  an  efficient  use  of  main  asmory. 

To  overcome  this  inefficiency,  a  new  architec- 
ture developed  which  supports  a  virtual  aemory  capability. 
The  important  characteristic  of  a  virtual  memory  architec- 
ture is  that  the  address  spice  of  a  user  program  is 
partitioned  into  a  set  of  independently  allocated  units, 
some  of  which  are  main  memory  resident  during  program  execu- 
tion, and  some  of  wdich  are  not.  With  -his  new  approach, 
the  system  software  loads  only  units  needed  for  execution, 
hence  a  greater  number  of  users  can  be  serviced  and  memory 
usage  is  more  efficient.   [ Ref .  32:  pp.  32-33] 

When  the  AD?  systea  does  not  permit  concurrent 
sharing  of  system  resources  or  processes  by  multiple  users, 
the  traditional  main  memory  protection  countermeasures  of 
base  and  bound  registsrs  or  locks  and  keys  are  sufficient  to 
enforce  an  isolation  policy.  aemory  base  and  bound  regis- 
ters are   set  by   the  system  software   to  specify   the  valid 


77 


upper  and  lower  main  memory  addresses  for  the  currently 
executing  process.  Any  attempt  by  the  process  to  fetch  from 
or  store  to  an  aidrass  outside  these  bounds  generates  an 
interrrupt  to  the  system  software.  When  a  different  process 
is  brouqht  in,  the  oase  and  bound  registers  are  changed  to 
describe  the  new  process1  mercery  area.  A  Lock  and  key  coun- 
termeasure  is  implemented  by  narking  each  location  in  main 
memory  with  a  lock  and  each  program  with  a  key.  When  the 
user  program  is  brought  into  lain  memory  for  execution,  the 
system  software  compares  the  kef  with  the  locks  and  unlocks 
only  those  areas  matched  by  th?  program's  key.  Each  fetch 
and  store  is  automatically  examined  by  the  hardware  to 
confirm  that  the  key  and  lock  natch. 

When  the  ADP  systen  permits  resource  sharing, 
these  traditional  countermeasures  are  not  adequate  because 
they  allow  programs  *ith  different  protection  attributes  to 
concurrently  access  the  same  area  of  main  memory.  Ref.  29 
recommends  a  solution  to  this  problem  that  incorporates  the 
protection  attributes  and  siz5  contraints  in  the  address 
translation  table.  This  table  is  used  by  the  system  soft- 
ware to  map  the  virtual  addresses  of  a  user  program  into  the 
physical  addresses  needed  in  main  memory.  [Ref.  29:  pp. 
108-114] 

Some  additional  countermeasures  that  are  needed 
to  protect  ADP  systems  which  process  sensitive  business  data 
are  as  follows. 

•  Ability  to  scrub  (zero  out!  residue  from  main  and  secon- 
dary memory  before  reallocation  to  another  user  process. 

•  A  memory  write  protection  feature  that  prevents  one 
program  from  overwriting  another.  Any  attempt  to  write 
generates  a  systen  interrupt. 
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b.  Dual  Execution  States 

The  duaL  executioa  states  of  privileged  and 
nonprivileged  allow  the  ZPU  to  maintain  the  two  execution 
domains  of  supervisor  and  user.  The  system  software 
executes  in  the  supervisor  donain,  thus  it  is  permitted 
immediate  access  to  all  systen  resources,  including  the 
ability  to  execute  privilsged  CPU  and  I/O  instructions.  On 
the  other  hand,  the  user's  process  executes  in  the  user 
domain  and  any  attempts  to  execute  a  privileged  instruction 
is  automatically  trapped  by  the  CPU.  Basically,  this  action 
generates  an  interrupt  which  signals  the  CPU  to  cnange  to 
the  privileged  state  and  allows  the  system  software  to 
execute  the  instruction  on  behaLf  of  the  user  process.  This 
countermeasure  is  available  on  almost  all  current  ADP 
systems. 

c.  Virtual    Machine    Monitors 

The  implementation  of  virtual  machine  monitors 
allows  each  user  program  to  have  its  own  virtual  machine 
uniquely  configured  for  its  needs.  The  virtual  monitor  is 
considered  to  be  a  functionally  complete  machine  with  i~s 
own  virtual  CPU,  meaory,  I/D  channels,  devices,  and  any 
other  virtual  resources  requested.  The  only  thing  it  lacks 
to  execute  a  user  program  is  the  physical  CPU.  The  physical 
CPU  is  allocated  between  virtual  monitors,  working  a 
specific  amount  of  tine  for  each  virtual  CPU  according  to  a 
specified  strategy.  This  allows  for  the  time-multiplexing 
of  each  virtual  nonitor  on  the  actual  hardware  and  the 
dynamic  reconfiguration  of  the  system  to  satisfy  the  needs 
of  a  user  program.  Since  each  user  process  is  contained  in 
a  specifically  configured  virtual  environment,  any  attempt 
to  access  a  systen  resource  oiitside  that  environment  auto- 
matically generates  a  system   interrupt.    Therefore  virtual 


machine  monitors   also  contribute  to   an   isolation   (self 
protection)  security  policy. 

2-   Processing  ControLs 

Processing  controls  it?  mainly  United  to  adminis- 
trative countermeasures  sued  as  standard  operating 
procedures  and  software  engineering  practices  that  indi- 
rectly protect  the  ADP  system  and  enhance  the  effectiveness 
of  the  technical  coun t ermeasures .  Some  of  the  controls  that 
should  be  considered  as  possible  candidates  are  as  follows. 

•  Users  should  be  restricted  to  programming  only  in 
higher-level  languages. 

•  Modifications  to  system  and  application  software  should 
be  implemented  by  a  two-person  control  strategy.  Two 
persons  must  sign  off  on  all  changes  to  the  system  soft- 
ware before  the  changes  are  made  in  the  operational 
version. 

•  A  Configuration  Management  PLan  which  addresses  software 
development  and  maintenance  procedures  should  be 
implemented. 

•  A  Contingency  Plan  which  describes  the  security  proce- 
dures for  responding  to  abnormal  operating  conditions 
should  be  established,  published,  and  periodically 
tested. 

3«   System  Error  Controls 

System  errors,  also  called  failures,  result  in  a 
degraded  or  unknown  performance  level  and  can  be  caused  by 
hardware  malfunctions,  software  errors,  or  operator  errors. 
Hardware  malfunctions  are  caused  by  such  things  as  the  CPU, 
memory  parity,  I/O  interface  and  communication  line,  or 
power  failure.  Software  errors  are  concerned  with  both 
operating   and   application   systems   deficiencies   and   are 
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attributed  to  incomplete  design  specifications  and/or  imple- 
mentation. And  lastly,  operator  errors  result  from  either 
badly  defined  operating  procedures  or  siaple  human  error. 
[Ref.  33:  pp.  104-105] 

In  developing  cour.termeasures  to  protect  against 
these  three  types  of  errors,  the  designer  must  consider 
error  prevention,  detection  and  recovery.  Error  prevention 
is  usually  satisfied  by  providing  sufficient  redundancy  so 
that  a  component  failure  does  not  degrade  performance. 
Error  detection  requires  the  AD?  system  to  be  capable  of 
recognizing  potential  hardware  and  software  malfunctions 
before  the  entire  system  baits.  Error  recovery  relates  to 
continuation  of  system  functions  after  an  error  has  occiired. 
Recovery  can  be  affected  at  several  levels,  depending  upon 
the  severity  and  impact  of  the  error.  For  example,  if  an 
error  could  crash  the  system,  tie  recovery  would  be  a  system 
restart;  or  if  a  program  attempted  to  read  past  +-he  er.d-of- 
file,  the  recovery  would  entail  an  error  message  to  the 
user.  Some  counter n easu res  that  have  been  suggested  by 
Carroll  [Ref.  20:  pp.  265-237]  and  IRK  Systems,  Inc. 
[Ref.  33:  pp.  129-173]  as  effective  in  counteracting  system 
errors  are: 

•  hierarchically  designei  fault- tolerant  AD?  systems 

•  redundancy  of  hardware  and  software  components 

•  automatic  backup  hardware  switchover 

•  transfer  of  critioal  systen  functions  from  software  to 
firmware  or  hardware 

•  dynamic  checking  of  the  system's  operating  state  with 
appropriate  recovery  actions  specified  should  an  illegal 
state  be  detected 

•  capability  for  logical  consistency  checks  (e.g.,  simulta- 
nicus  interrupt  prevention,  device  address  and  existence 
check,   and  time  deck  on   propagation  of  signals  between 
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devices)    with   appropriate  recovery   actions   initiated 
should  an  inconsistency  be  realized 

•  capability  for  selective  t =r mination,  graceful  degrada- 
tion,  automatic   initiation  of  diagnostics,    and  graded 

(warm/cold)  restarts 

•  memory  parity  and  addrsss  validation 

•  replication  of  critical  syststn  files  including  data  bases 
and  audit  logs 

•  employment  of  data  integrity  controls  such  as:  checks 
for  reasonableness,  consistency,  and  range,  use  of 
checksum  totals  aid  parity  daring  data  transfers,  and 
maintenance  of  a  transaction  journal 

•  timing  and   sequence  checks   pertinent  to   I/O  operations 

(e.g.,  I/O  instruction  execution  and  I/D  transmission) 


32 


7.  RECOMMENDATIONS 

A.   RECOMMENDED  SPLICE  FUNCTIONAL  SECURITY  MODULE 

This  section  provides  recommended  design  specifications 
for  a  software  Security  .lodule  to  be  incorporated  into  the 
functional  design  of  the  SPLICE  Local  Area  Network  (LAN). 
The  specifications  ace  based  upon  the  assumption  that  all 
data  handled  within  the  3PLICE  LANs  will  be  classified  no 
higher  than  Sensitive  Business  Data.  The  design  specifica- 
tions recommended  ii  this  section  satisfy  the  protection 
reguireraents  set  forth  in  Refs.  10  and  11. 

As  discussed  earlier,  a  complex  data  processing  environ- 
ment like  SPLICE  is  usually  protected  by  enforcing  the  four 
ADP  security  policies  of  authentication,  access  control, 
surveillance,  and  integrity.  lie  SPLICE  Security  Module  has 
been  designed  as  a  collection  of  submodules,  with  a  recom- 
mended software  submodule  fo~  each  policy  area  except 
integrity.  The  integrity  requirements  of  SPLICE  have 
already  been  addressed  in  Ref.  13  and,  if  implemented,  will 
be  adequate.  The  integrity  requirements  address  such  things 
as  memory  protection  features,  change  control  procedures, 
memory  parity,  data  integrity  controls,  and  system  consis- 
tency checks.  Tha  r ecommanded  security  mcdule  is 
specifically  tailored  to  satisfy  the  security  requirements 
of  the  SPLICE  LAN  and  should  not  be  construed  as  being 
endorsed  for  all  such  ea vironnents.  The  terms  used  to 
describe  the  Security  Module  and  its  interactions  with  the 
other  functional  modules  of  tha  SPLICE  LAN  have  been  taken 
from  Ref.  34. 
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The   functions  of   ths   SPLICE   Security  Module   are   as 
follows: 

•  Authentication  of  the  user  when  accessing  the  SPLICE 
Configur  ation. 

•  Authentication  of  terminals  and  peripheral  devices  when 
requesting  or  performing  a  service. 

•  Maintenance  of  an  access  control  mechanism  which  enforces 
the  access  rights  as  prescribed  for  subjects  and  objects 
of  the  local  SPLI3E  Configuration  and  validates  requests 
for  access  to  the  SPLICE  LAN  and  the  Defence  Data 
Network. 

•  Maintenance  of  an  online  secarity  auditing  mechanism  that 
logs  appropriate  security  related  information  required  to 
support  subsequent  analysis  efforts. 

1.   Authentication 

In  order  to  enforce  an  authentication  policy, 
authorized  use  of  SPLICE  resources  must  be  controlled  by 
both  an  administrative  and  a  software  ccuntermeasure.  The 
administrative  ccuntermeasure  requires  that  each  user  and 
device  be  uniquely  identifiable  within  the  SPLICE  LAN.  The 
software  co untermeasur e  necessitates  the  design  of  software 
submodules  which  function  to  identify  users,  terminals,  and 
peripherals . 

Chapter  IV  presented  in  detail  numerous  mechanisms 
considered  effective  in  protecting  a  password  authentication 
count ermea sure.  It  is  recommended  that  those  mechanisms  be 
evaluated  for  their  applicability  to  the  detailed  design  of 
the  authentication  sub  module. 
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a.       Authentication    of    Terminals    and   Users 

The  software  submoiule  for  authenticating  termi- 
nals and  users  shouli  be  invoked  by  the  Front  End  Processor 
(FEP)  Module  when  the  user  initially  attempts  to  log  on  to 
the      local      SPLICE      Configuration     (local      system).  It      is 

assumed  that  the  FEP  Module  can  recognize  when  a  user  is 
logging  on  to  the  local  system  and  that  it  can  invoke  the 
submoduie   when    appropriate. 

The  terminal's  identity  should  be  checked  by 
reguiring  the  terminal  to  transmit  a  security  code  in 
response  to  an  interrogation  command.  The  code  is  then 
matched  against  a  table  of  authorized  terminal  security 
codes.  If  a  match  is  found,  the  logon  procedure  continues. 
Otherwise,  the  security  auditing  submoduie  (to  be  addressed 
later)  is  invoked  and  appropriate  actions  for  responding  to 
a  security  violation  are  taken.  After  the  terminal's  iden- 
tity is  verified,  the  user's  identification  number  and 
password  are  checked  in  a  similar  manner.  If  a  match  is 
found,  the  logon  procedure  is  completed  and  control  passed 
back  to  the  FEP  Module.  If  no  match  is  found,  the  security 
auditing  submoduie  is  invoked  as  before  and  control  is 
passed  back  to  the  F3P  Module  after  appropriate  actions  have 
been   taken. 

It  is  recommended  that  the  authentication 
submoduie  for  terminals  and  users  be  located  in  the  same 
physical  machine  as  the  FEP  Module  for  each  local  system. 
This  recommendation  is  based  on  the  need  to  restrict  a 
nonverified  terminal  and  user  to  as  little  of  -"rhe  local 
system  as  feasible.  This  subnodule  will  only  be  invoked 
when  a  user  (local,  remote  or  satellite)  initially  logs  on 
to    the    local  system. 


b.   Authentication  of  Peripherals 

The  authan tication  submodule  for  verifying  the 
identity  of  a  peripheral  device  has  not  been  examined  due  to 
the  lack  of  detailed  design  specifications  concerning  how 
the  Peripheral  Management  (PS)  Module  interacts  with  the 
local  system.  Once  the  design  has  been  completed,  it  is 
recommended  that  the  countermeasures  presented  in  Chapter  IV 
Section  A.  2  be  reviewed  for  their  applicability. 

2.   Access  Control 

After  the  user's  identity  is  verified,  the  FEP 
Module  forwards  all  subsequent  user  messages  to  the  Terminal 
Management  (TM)  Module.  lie  TM  Module  responds  by 
requesting  that  the  Session  Services  (SS)  Module  establish 
and  maintain  a  user  session.  After  a  session  has  been 
established,  the  SS  Module  examines  each  user  request  and 
invokes  the  appropriate  generalized  functional  module  needed 
for  accomplishing  the  task  requested.  It  is  recommended 
that  the  SS  Module  invoke  the  access  control  submodule  to 
validate  the  user's  authorization  rights  before  it  invokes 
any  other  functional  nodule  on  behalf  of  the  user. 

The  access  control  submodule  should  perform  two 
types  of  authorization  control.  First,  if  the  user  task 
requests  access  to  the  SPLICE  LAN  or  the  Defense  Data 
Network,  the  access  control  subnodule  should  ensure  that  the 
user  has  been  authorized  such  an  access.  The  second  type  of 
control  involves  granting  or  denying  a  user  (either  local, 
remote  or  satellite)  access  to  a  local  system  object  such  as 
a  file,  directory,  or  peripheral  device  to  perform  some 
action  such  as  read,  write  or  execute  on  that  particular 
object.  If  the  request  is  not  allowed,  the  security 
auditing  submodule  is  invoked  and  appropriate  action  is 
taken. 


36 


The  design  of  the  accsss  control  submodule  should  be 
based  on  the  authority  item  technique  presented  in  Ref.  29. 
This  design  specification  reduces  the  time  required  to  grant 
a  user  authorization  request  and  allows  authority  items  to 
be  easily  modified  when  changes  are  made  to  the  authoriza- 
tion rights  of  a  user  (subject)  or  the  access  capabilities 
of  an  object.  The  implementation  of  this  countermea sure 
requires  that  the  authorization  rights  of  users  and  access 
capabilities  of  objects  be  explicitly  defined  and  maintained 
online  for  use  by  the  access  control  submodule.  It  is 
recommended  that  the  accass  control  submodule  be  colocated 
with  the  SS  Module  to  minimize  the  time  required  to  validate 
a  user's  authorization . 

3-   Surveillance 

In  order  to  enforce  a  surveillance  policy,  it  is 
recommended  that  a  security  auditing  submodule  be  incorpo- 
rated in  the  design  of  the  SPLICE  Security  Module.  No 
particular  location  for  this  submodule  is  recommended,  as  it 
could  be  a  candidate  for  relocating  from  one  physical 
machine  to  another  as  necessary  to  improve  the  overall 
performance  of  the  3PLICE  Configuration.  This  submodule 
will  be  invoked  by  the  TM  Module,  the  55  Module,  the  PM 
Module,  and  any  other  module  which  can  recognize  a  security 
violation  or  system  error.  Ihe  appropriate  actions  for  the 
submodule  to  take  when  invoked  are  to  log  the  event,  to 
notify  the  central  system  operator  that  an  error  or  viola- 
tion has  occurred,  and  if  the  error  or  violation  is  severe 
enough,  the  user's  log-on  or  session  should  be  terminated. 
The  security-related  information  recorded  by  this  submodule 
should  include  at  a  minimum  trie  following. 

•   A  system   access  Log   which  identifies   who  accessed   the 
system,   what  terminal  the  aocess  was  made  from,   whether 
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the  access  attempt  was  successful,   and  the  date  and  time 
it  occurred. 

•  An  input/output  log  which  identifies  who  requested  the 
service,  what  function  (read,  write,  enter,  print)  was 
provided,  whether  the  function  was  successful,  and  the 
date  and  time  it  occurred. 

•  A  processing  log  which  records  appropriate  security- 
related  information  about  system  errors  and  security 
violations. 

B.   OTHER  RECOMMENDED  SPLICE  SECURITY  MEASURES 

It  is  recommended  that  NAVSOPINST  5519. 6A  be  revised  and 
reissued  to  accomoflace  the  mininum  mandatory  counter  measures 
listed  in  Appendix  J  of  Ref.  13,  which  was  issued  subsequent 
to  NAVSUPINST  5510. 6A.  This  would  allow  the  mandatory  coun- 
termeasures  to  be  included  by  reference  in  the  next  version 
of  the  SPLICE  Security  and  Risk  Analysis  Plan  [Ref.  11]. 

The  "SPLICE  unbrella"  contains  many  software  products 
which  are  being  developed  by  Central  Design  Activities  for 
distribution  to  multiple  activities.  It  is  recommended  that 
the  SPLICE  Froject  Officer  insure  that  each  software  product 
is  certified  in  accordance  with  OPNAVINSI  5239. 1A  prior  to 
distribution  [Ref.  13:  p.  3-1]. 

In  the  design  of  software  products,  the  software 
controls  listed  in  Appendix  I  of  Ref.  10  must  be  incorpo- 
rated. It  should  also  be  notri  that  contractor  developed 
software  and  count=r measures  are  also  subject  to  the 
requirements  of  Ref.  10. 

It  is  recommeded  that  the  following  actions  be  taken  to 
help  insure  that  the  risk  in  SPLICE  is  quantified  and 
managed  at  an  acceptable  level. 

•  A  Network  ADP  Security  Officer  should  be  designated  early 
in  the  lifecycle  of  the   SPLICE  Project.    The  individual 
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so  designated  should  be  givan  a  position  high  enough  in 
the  project  organization  ana*  appropriate  authority  and 
resources  to  maaage  the  SPLI3E  Risk  Analysis  Program  and 
effect  the  necessary  design  changes  and  operational 
reguirements. 

•  The  Network  ADP  Security  Officer  should  develop  and  main- 
tain a  comprehensive  checklist  of  threats  which  are 
potentially  present  at  any  SPLICE  activity.  The  reader 
is  invited  to  review  the  works  of  Martin  (1973),  N3S  FIPS 
31  (1974),  Ref.  20,  and  Ref.  22  for  recommended  lists  of 
threats.  The  checklist  should  be  made  available  to 
activity  risk  analysis  teams. 

•  The  Network  ADP  Security  Officer  shouli  be  given  cogni- 
zance of  all  activity  security  incident  reports  [Ref.  10: 
p.  8-2]  in  order  to  identify  and  monitor  vulnerabilities 
which  potentially  = xist  in  the  SPLICE  Network. 

•  A  risk  management  training  program  should  be  established 
to  provide  a  consistent  Risk  Management  Program 
throughout  the  SPLICE  Network.  A  list  of  responsibili- 
ties for  ADP  security  training  is  provided  in  Chapter  10 
of  Ref.  10. 

•  The  appropriate  Inspector  3eneral  review  program  for 
every  SPLICE  activity  should  incorporate  a  security 
review,  as  defined  in  0PN"!\VINST  5239.  1A  [Ref.  10:  p. 
8-1  ]. 

C.   FUTURE  RESEARCH  QUESTIONS 

1-   Y.^  I  Mi  liSI!  2t    Security,  loiule  Specifications 

This  thesis  provides  a  formal  program  for  risk 
management,  but  does  not  attempt  to  quantify  the  risk  in  any 
particular  activity.  Additional  research  should  be  accom- 
plished in  at  least  one  of  ==veral  ways.  The  risk  of 
operating  can  be   estimated  by  simulating  a   "typical  SPLICE 
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activity."  This  would  require  complete  enumeration  of  all 
assets  in  the  seven  resource  categories,  and  a  listing  of 
all  "potential"  threats  facing  a  SPLICE  activity. 

Another  research  method  would  be  to  examine  an 
existing  Navy  activity  that  is  designated  to  become  a  SPLICE 
activity.  By  evaluating  the  changes  in  the  data  processing 
environment  due  to  the  SPLICE  configuration,  their  impact  on 
the  ADP  security  posture  of  the  activity  can  be  properly 
examined. 

By  using  one  of  these  research  methods,  the  recom- 
mended Security  Functional  Module  can  be  validated  and,  if 
needed,  additional  co untermeasnres  can  be  specified  for  in 
the  design  of  the  SPLICE  software  or  implemented  at  the 
operational  SPLICE  activities. 

2.   Critigue  of  Risk  Hanajsasnt  Program 

The  Risk  Management  Program  models  presented  in 
Chapter  3  formalize  the  concepts  proposed  by  Courtney 
[Eef.  3],  NBS  [Ref.  17],  and  Fitzgerald  [Ref.  19],  and 
adopted  by  the  Navy  in  the  DON  ADP  Security  Program 
[Ref.  10].  Although  the  models  presented  here  reflect  the 
established  concepts  of  tae  various  references,  no  attempt 
has  been  made  to  analyze  the  validity  of  the  concepts. 

Both  the  Asset  Loss  Determination  Model  and  the 
Threat  and  Vulnerability  Evaluation  Model  are  essentially 
exponential  utility  functions,  which  exhibit  decreasing 
marginal  utility.  Kith  respect  to  asset  losses,  this 
implies  that  an  asset  loss  of  $1,000  with  a  total  asset  loss 
level  of  $10,000  is  not  as  significant  as  an  asset  loss  of 
$1,000  when  the  asset  loss  level  is  at  3100,000.  A  simple 
question  arises  in  this  reasoning.  To  a  computer  system 
user,  is  the  tenth  day  of  doing  without  service  less  impor- 
tant than  the  first  or  second?  Likewise,  is  losing  the  use 
of  a   tape  drive  less  significant   if  you  have   already  lost 
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five  tape  drives  thai  it  is  whaa  you  have  lost  none?  There 
may  exist  an  argument  that  ths  marginal  utility  should 
increase   with    increasing   asset    Losses. 

In  threat  and  vulnerability  evaluation,  less  signi- 
ficance is  similarly  placed  on  narginal  risk,  as  the  activity 
becomes  more  vulnerable  cc  mora  threats  are  present.  Is  the 
risk  of  a  fourth  or  fifth  attaok  not  as  significant  as  the 
second    or   third? 

Finally,  the  Navy's  risk  management  decision 
problem   should      be    more    fully    modeled.  Currently    explicit 

constraints  are  plaoed  on  ths  activity  manager  by  the  DAA 
who  sets  a  maximum  aoceptable  Total  ALE.  Although  not  docu- 
mented in  the  Navy  program,  the  setting  of  the  maximum 
acceptable  Total  ALE  is  done  by  use  of  the  DAA's  utility 
function.  Certainly  this  choioa  is  made  in  light  of  other 
investment  alternati/a s,  and  with  regard  to  the  Navy  system 
of   incentives,    rewards,    and   penalties. 
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APPENDIX  A 
LISP  OF  ACRONYMS 

ADP  Automatic  Data  Processing  (See  EDP) 

ADPSO  Automatic   Data   Processing   Security 

Of ficer 

ADPSSO  Aatomatic  Data        Processing  System 

Security   Dfficer 

ALE  Annual    Loss    Expectancy 

ARPANET  Advanced        Research  Projec-s        Agency 

Network 

CPU  Central  Processing  Unit 

CRC  Cyclical  Redundancy  Check 

CRT  Cathode  Riy  Tube 

DAA  Designated  Approving  Authority 

DDN  Defense  Data  Network 

DES  Data  Encryption  Standard 

FIPS  Federal  Information   Processing  Standard 

(National  Bareau  of  Standards) 

GAO  General  Accounting  Office 

I/O  la  put/output 

IP  Internet  Protocol 

IPLI  Internet  Private  Line  Interface 

LCN  Local  Computer  Network 
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MC 

NBS 

NSO 

OMB 

SPLICE 

ST&E 
TASO 
TCP 

VMM 


Monitoring  Cenzer 

National  Bureau  of  Standards 

Network  Security  Officer 

Dffice  of  Management  and  Budget 

Stock    Point    Logistics     Integrated 
Communications  Environment 

Security  Test  and  Evaluation 

Terminal  Area  Security  Officer 

Transmission  Control  Protocol 

Virtual  Machine  Monitor 
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APPENDIX  3 
DEFINITIONS 

The  majority  Df  the  defiaitior.s  contained  herein  are 
taken  from  the  Department  of  the  Navy  Automatic  Data 
Processing  Security  Program  Manual,  OPNAVINST  5239. 1A 
[Ref-  10]-  All  definitions  not  from  OPNAVINST  5239. U  are 
referenced. 

ACCEPTABLE  LEVEL  OF  RISK.  A  julicious  and  carefully  consid- 
ered assessment  by  the  appropriate  Designated  Approving 
Authority  (DAA)  that  an  automatic  data  processing  (ADP) 
activity  or  network  meets  the  minimum  requirements  of  appli- 
cable security  directives  and  the  provisions  of  OPNAVINST 
5239.1  A.  The  assessnent  shouli  take  into  account  the  value 
of  ADP  assets;  threats  and  vulnerabilities;  countermeas ures 
and  their  efficacy  ii  compensating  for  vulnerabilities;  and 
operational  requirements. 

ACCESS.  The  ability  and  the  means  to  approach,  communicate 
with  (input  to  or  receive  outpjt  from),  or  otherwise  make 
use  of  any  material  or  component  in  an  ADP  system. 
Personnel  only  receiving  computer  output  products  from  the 
ADP  system  and  not  inputting  to  or  otherwise  interacting 
with  the  system  (i.e.,  no  "hands  on"  or  other  direct  input 
or  inquiry  capabilityl  are  not  considered  to  have  ADP  system 
access  and  are  accordingly  not  subject  to  the  personnel 
security  requirements  of  OPNAVINST  5239.1  A.  Such  output 
products,  however,  shall  either  be  reviewed  prior  to  dissem- 
ination or  otherwise  determined  to  be  properly  identified  as 
to  content  and  classification.   * Ref .  35] 
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ACCESS  AUTHORIZATION.  Password  and/or  user  id  required  to 
meet  security  restrictions  for  the  resource  being  accessed. 
[Ref.  13] 

ACCREDITATION.  A  policy  decision  by  the  responsible  DAA 
resulting  in  a  formal  declaration  that  appropriate  security 
countermeasures  have  been  properly  implemented  for  the  ADP 
activity  or  network,  so  that  the  activity  or  network  is 
operating  at  an  acceptable  level  of  risk.  The  accreditation 
should  state  the  mode  of  operation  and  any  operating  limita- 
tions applicable  to  the  ADP  activity  or  network. 

ADMINISTRATIVE  SECURITY.  The  management  constraints;  opera- 
tional, administrative,  and  accountability  procedures;  and 
supplemental  controls  established  to  provide  an  acceptable 
level  of  protection  for  data.  Synonymous  with  procedural 
security.   [Ref.  3S] 

ADP  ACTIVITY.  Any  organizational  entity  with  responsibili- 
ties for  developing,  operating,  or  maintaining  an  ADP  system 
or  network. 

ADP  SECURITY.  Measires  reguiced  to  protect  against  unau- 
thorized (accidental  or  intentional)  disclosure, 
modification,  or  destruction  of  ADP  systems  and  data,  and 
denial  of  service  to  process  data.  ADP  security  includes 
consideration  of  all  hardware/software  functions,  character- 
istics, and/or  features;  operational  procedures, 
accountability  procedures,  and  access  controls  at  the 
central  computer  facility,  remote  computer,  and  terminal 
facilities;  management  constraints;  physical  structures  and 
devices;  and  personnel  and  communication  controls  needed  to 
provide  an  acceptable  level  of  risk  for  the  ADP  system  and 
for  the  data  or  information  contained  in  the  system. 
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ADP  SECURITY  STAFF.  Individuals  assigned  and  functioning  as 
action  officials  for  ADP  security  within  their  respective 
organization: 


ADP  Security  Officer 
ADP  Systems  Security 
Network   Security   Officer    (N50) 

f fir  er 


y  Officer  (ADPSOl 
ADP  Systems  Security  Officer  (ADPSSO) 
:urity  Officer  (N50) 

,ty  Officer  (TASO) 
ystem  Security  Officer  (OISSO) 


Terminal  Area  Security  Officer  (TASO) 
Office  Informatics  System 


ADP  SYSTEM.  An  assembly  of  conputer  equipment,  facilities, 
personnel,  software,  and  procedures  ccnfigured  for  the 
purpose  of  classifying,  sorting,  calculating,  computing, 
summarizing,  storing  and  retrieving  data  and  information 
with  a  minimum  of  iiman  inters ention.  An  ADP  system  as 
defined  for  purposes  of  OPNAVINST  5239. 1A  is  the  totality  of 
automatic  data  processing  equipment  (ADPE)  and  includes: 

a.  General  and  special  purpose  computers  (e.g.,  digital, 
analog,  or  hybrid  computer  equipment) ; 

b.  Commercially  available  components,  these  produced  as  a 
result  of  research  i nd  development,  and  the  equivalent 
systems  created  frcm  them,  regardless  of  size,  capacity,  or 
price,  which  are  utilized  in  the  creation,  collection, 
storage,  processing,  communication,  display,  or  dissemina- 
tion of  data; 

c.  Auxiliary  or  accessorial  equipment,  such  as  data  commu- 
nications terminals,  source  data  automation  recording 
equipment  (e.g.,  optical  character  recognition  equipment, 
paper  tape  typewriters,  magnetic  tape  cartridge  typewriters, 
and  other  data  acquisition  devices),  data  output  equipment 
(e.g.  digital  plotters  and  conputer  output  micrcf iimers) , 
etc.,  to  be  used  in  support  of  digital,  analog,  or  hybrid 
computer  equipment,  either  cable-connected,  wire-connected, 
or  self-standing; 

d.  Electrical  accounting  machines  used  in  conjunction  with 
or  independently  of  iigital,  analog  or  hybrid  computers;  and 
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e.  Computer  equipment  which  supports  or  is  integral  to  a 
weapons  system.   [Ref.  35] 

ANNUAL  LOSS  EXPENTANCY  (ALE).    The  ALE   of  an  ADP  system  or 

activity  is  the  expected  yearly  dollar  value  loss  from  the 

harm  to  the  system  or  activity  by  attacks  against  its 
assets. 

ASSET.  Any  software,  data,  hardware,  administrative,  phys- 
ical, comm unicatins,  or  personnel  resource  within  an  ADP 
system  or  activity.   See  ADP  RESOURCES. 

ATTACK.  The  realization  of  a  threat.  How  often  a  threat  is 
realized  depends  on  such  factors  as  the  location,  type,  and 
value  of  information  being  processed.  Thus,  short  of  moving 
the  system  or  facility  or  radically  changing  its  mission, 
there  is  usually  no  way  that  tie  level  of  protection  can 
affect  the  frequency  of  attack.  The  exceptions  to  this  are 
certain  human  threats  where  effective  security  measures  can 
have  a  deterrent  effect.  The  fact  that  an  attack  is  made 
does  not  necessarily  n ean  that  it  will  succeed.  The  degree 
of  success  depends  on  the  vulnerability  of  the  system  or 
activity  and  the  effectiveness  of    existing  count ermeasur es. 

AUDIT.  To  conduct  ths  independent  review  and  examination  of 
system  records  and  activities  ia  order  to  test  for  adequacy 
of  system  controls,  to  ensure  compliance  with  established 
policy  and  operational  procedures,  and  to  recommend  any 
indicated  changes  in  controls,  policy,  or  procedures. 

a.  Internal  Security  Audit.  An  audit  conducted  by 
personnel  responsible  to  the  management  of  the  orgainzation 
being  audited. 

b.  External  Security  Audit.  An  audit  conducted  by  an 
organization  independent  of  the  one  being  audited. 
[Ref.  36] 
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BROWSING.  The  act  of  searching  through  storage  to  locate  or 
acguire  information  without  necessarily  knowing  the  exis- 
tence or  the  forma^  of  the  information  being  sought. 

CENTRAL  COMPUTER  FACILITY.  One  or  more  computers  with  their 
peripheral  and  storage  units,  central  processing  units,  and 
communications  equipment  in  a  single  controlled  area.  This 
does  not  include  remote  computer  facilities,  peripheral 
devices,  or  terminals  which  are  located  outside  the  single 
controlled  area,  even  though  they  are  connected  to  the 
central  computer  facility  by  approved  communication  links. 
[Ref.  37] 

CENTRAL  SYSTEM  OPERATOR.  A  system  user  who  by  virtue  of 
security  access  control  authorization  has  access  to  the  user 
mode  and  the  central  system  operator  moie  of  the  command 
interpreter.   [Ref.  13] 

COMHUNICATICNS  SECURITY.  The  protection  resulting  from  all 
measures  designed  to  den/  unauthorized  persons  information 
of  value  which  migit  be  derived  from  the  possession  and 
study  of  telecommunications,  or  to  mislead  unauthorized 
persons  in  their  interpretation  of  the  results  of  such 
possesion  and  study.  Also  called  C0MS2C.  Communications 
security  includes  cry ptosecurit y,  transmission  security, 
emission  security,  and  physical  security  of  communications 
security  materials  and  information. 

CONFIGURATION  MANA3E3ENT.  The  use  of  procedures  appropriate 
for  controlling  changes  to  a  system's  hardware  and  software 
structure  for  the  purpose  of  insuring  that  such  changes  will 
not  lead  to  decreased  data  security. 

CONTINGENCY  PLANS.  A  plan  for  emergency  response,  backup 
operations,  and  post- disaster  recovery  maintained  by  an  ADP 
activity  as  a  part  of  its  security  program.   A  comprehensive 
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consistent  statement  Df  all  the  actions  (plan)  to  be  taken 
before,  during,  and  after  a  disaster  (emergency  condition), 
along  with  documented,  tested  procedures  which,  if  followed, 
will  ensure  the  availability  of  critical  ADP  resources  and 
which  will  facilitate  maintaining  the  contimuity  of  opera- 
tions   in   an  emergency    situation. 

CQUNTERMEASURE.       See    section    II. A. 4. 

DATA    INTEGRITY.  The    state      that    exists      when    computerized 

data  is  the  same  as  that  in  the  source  documents  and  has  not 
been  exposed  to  accidental  or  intentional  modification, 
disclosure,    or    destruction.      *Ref.    36] 

DATA    LEVEL. 

Level  I.   Classified  lata. 

Level  II.    Unclassified  data   requiring  special  protection; 

for  example,  Privacy  Act,   For  Dfficial  Use  Only,   technical 

documents  restricted  to  limited  distribution. 

Level  III.   Ail  other  unclassified  data. 

DATA  SECURITY.  The  protection  of  data  from  unauthorized 
(accidental  or  intentional)  aodif icaiton,  destruction,  or 
disclosure.   [Ref.  35] 

DESIGNATED  APPROVING  AUTHORITY  (DAA) .  An  official  assigned 
responsibility  to  accredit  ADP  elements,  activities,  and 
networks  under  the  official's  jurisdiction. 

ESCORT(S).  Duly  designated  personnel  who  have  appropriate 
clearances  and  access  authorizations  for  the  material 
contained  in  the  system  and  ar5  sufficiently  knowledgeable 
to  understand  the  security  inpiications  Df  and  to  control 
the  activities  and  aocess  of  the  individual  being  escorted. 
[Ref.  37] 
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HARDWARE  SECURITY.  Computer  equipment  features  cr  devices 
used  in  an  ADP  system  to  preclude  unauthorized  accidental  or 
intentional  modification,  disclosure,  or  destruction  of  ADP 
resources. 

MATERIAL.  "Material"  refers  to  data  processed,  stored,  or 
used  in  and  information  generated  by  an  ADP  system  regard- 
less of  form  or  medium,  e.g.,  programs,  reports,  data  sets 
or  files,  records,  and  data  elenents.   [Ref.  35] 

NEED-TO-KNOW.  The  necessity  for  access  to,  knowledge  of,  or 
possession  of  certain  information  required  to  carry  out 
official  duties.  Res ponsibilit y  for  determining  whether  a 
person's  duties  require  that  possession  of  or  access  to  such 
information  and  whether  the  individual  is  authorized  to 
receive  it  rests  upon  the  individual  having  current  posses- 
sion, knowledge,  or  control  of  the  information  involved  and 
not  upon  the  prospective  recipient  (s) . 

NETWORK.  The  int ecc onnectioa  of  two  or  more  ADP  central 
computer  facilities  that  provides  for  the  transfer  or 
sharing  of  ADP  resources.  The  ADP  network  consists  of  the 
central  computer  facilities,  the  remote  terminals,  the 
interconnecting  comman icat ion  links,  the  front-end  proces- 
sors, and  the  telecommunications  systems. 

OPERATING  SYSTEM  (D/S|  .  An  integrated  collection  of  service 
routines  for  supervising  the  sequencing  and  processing  of 
programs  by  a  computer.  Operating  systems  control  the  allo- 
cation of  resources  to  a  user  and  their  programs  and  play  a 
central  role  in  ensuring  the  secure  operation  of  a  computer 
system.  Operating  systems  may  perform  debugging,  input- 
output,  accounting,  resource  allocation,  compilation, 
storage  assignment  tasks,  and  other  "system"  related  func- 
tions. Synonymous  with  terms  such  as  "Monitor," 
"Executive,"  "Control  Program,"  and  "Supervisor."   [Ref.  35] 
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PASSWORD.  A  protested  word  du  string  of  characters  that 
identifies  cr  authenti cates  a  user  for  access  to  a  specific 
resource  such  as  a  data  set,  file,  or  record. 

PERSONAL  DATA.  Data  abojt  an  individual  including,  but  not 
limited  to,  education,  financial  transactions,  medical 
history,  gualif ication s,  servioe  data,  criminal  or  employ- 
ment history  which  ties  the  data  to  the  individual's  name, 
or  an  identifying  number,  synbol,  or  other  identifying 
particular  assigned  to  the  individual,  such  as  a  finger  or 
voice  print  or  a  photograph. 

PERSONNEL  SECURITY.  Tha  procedures  established   to  ensure 

that   each  individual  has  a   background   which  indicates   a 

level  of  assurance  of  trustworthiness  which  is  commensurate 

with  the  value  of  ADP  resources  which  the  individual  will  be 
able  to  access. 

PHYSICAL  SECURITY.  Piysical  security  is  the  protection  of  a 
material  entity  (property)  fron  disruption  of  its  safe  and 
secure  state  and  is  concerned  with  physical  measures 
designed  to  safeguard  personnel,  to  prevent  unauthorized 
access  to  equipment,  facilities,  material,  and  documents, 
and  to  safeguard  then  against  espionage,  sabotage,  damage, 
and  theft. 

a.  The  use  of  locks,  badges,  and  similar  measures  to 
control  access  to  the  central  computer  facility. 

b.  The  measures  reqiired  for  the  protection  of  the  struc- 
tures housing  the  central  computer  facility  from  damage  by 
accident,  fire,  environmental  hazards,  loss  of  utilities, 
and  unauthorized  access. 

REVIEW  AND  APPROVAL.  The  process  whereby  information 
pertaining  to  the  security  and  integrity  of  an  ADP  activity 
or  network  is  collected,  analyzed,  and  submitted  to  the 
appropriate  DAA  for  accreditation  of  the  activity  or 
network. 
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RESOURCE-SHARING   COMPUTER    SYSTEH.  A      computer    system    which 

uses  its  resources,  including  input/output  (I/O)  devices, 
storage,  central  prDcessor  (arithmetic  and  logic  units), 
control  units,  and  software  processing  capabilities,  to 
enable  one  cr  more  users  to  manipulate  data  and  to  process 
co-resident  programs  in  an  apparently  simultaneous  manner. 
The  term  includes  systems  with  one  cr  more  capabilities 
commonly  referred  to  as  timesharing,  multiprogramming, 
multi-accessing,  mult i-processin g ,  or  concurrent  processing. 
[Ref.    35] 

RISK.      See    section    II.  A.  1. 

RISK  ANALYSIS  (ASSESSMENT)  .  A. n.  analysis  of  system  assets 
and  vulnerabilities  to  establish  an  expected  less  from 
certain  events  based  on  estimated  probabilities  of  the 
occurrence  of  these  svents.  Tie  purpose  of  a  risk  assess- 
ment is  to  determine  if  count armeasures  are  adequate  to 
reduce  the  probability  of  loss  or  the  impact  of  loss  to  an 
acceptable    level. 

SECURITY  ACCESS  CONSTRAINTS.  The  process  and  file  access 
restrictions  imposed  by  tha  security  requirements. 
[Ref.    13] 

SECURITY  FILE.  File  containing  user  ids  and  associated 
access   constraints.      [Ref.     13] 

SECURITY      LOG.  Data      file    containing      violations      of      the 

security    requirements.       [Ref.    13] 

SECURITY  OFFICER.  Designated  individual  who  is  responsible 
for        maintaining        the        security  procedures        for        the 

installation.       [Ref.    13] 

SECURITY    INSPECTION.  An    examination    of      an    ADP      system    to 

determine  compliance  with  ADP  security  policy,  procedures, 
and    practices. 
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SECURITY   SPECIFICATIONS.    A   detailed   inscription  of   the 
count ermeasures   required   to   protect  an   ADP   activity   or 
network  from    unauthorized   (accidental   or   intentional) 
disclosure,  modification,  and  destruction  of  data,  or  denial 
of  service. 

SECURITY  TEST  AND  EVALUATION  (STSE).  An  examination  and 
analysis  of  the  security  features  of  an  ADP  activity  or 
network  as  they  have  been  applied  in  an  operational  environ- 
ment to  determine  ths  security  posture  of  the  activity  or 
network  upon  which  an  accreditation  can  be  based. 

SECURITY  VIOLATION.  Any  attempt  to  gain  access  to  the  oper- 
ating system,  the  operating  system  files  and  executable 
modules,  or  systen  user  files  and  executable  modules. 
[Ref.  13] 

SENSITIVE  BUSINESS  DATA.  Data  which  requires  protection 
under  Title  18,  USC  1905,  and  other  data  which  by  its  nature 
requires  controlled  distribution  or  access  for  reasons  other 
than  the  fact  that  it  is  classified  or  personal  data. 
Sensitive  Business  Data  is  rscognized  in  the  following 
categories : 

a.  For  Official  Use  Only--Re guiring  confidentiality  of 
information  derived  from  InspectDr  General,  authority,  or 
other  investigative  activity. 

b.  Financi  al--Reguirir.g  protection  to  ensure  the  integrity 
of  funds  or  other  fiscal  assets. 

c.  Sensitive  Manage  n ent--Regui ring  protection  to  defend 
against  the  loss  of  property,  material,  or  supplies  or  to 
defend  against  the  disruption  of  operations  or  normal 
management  practices,  etc. 

d.  Proprietary — RegiLring  protection  to  protect  data  or 
information  in  conformance  with  a  limited  rights  agreement 
or  which  is  the  exclusive  property  of  a  civilian  corporation 
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or  individual  and  which  is  on  loan  to  the  Government  for 
evaluation  or  for  its  proper  us  =  in  adjudicating  contracts. 
e.  Privileged—Requiring  protection  for  conformance  with 
business  standards  or  as  required  by  law.  (Example: 
Government- developed  information  involving  the  award  of  a 
contract.) 

SPLICE  CONFIGURATION.    An   integrated  set  of   six  hardware/ 

software   systems   rs- quired   to   achieve  the   functional, 

performance  and  capacity  requirements  of  the  SPLICE 
specifications.   [Ref.  13] 

SPLICE  LOCATION.  One  or  more  SPLICE  configurations  in  the 
same  geographical  area  (on  the  same  Local  Computer  Network) 
connected  to  Governman t-furnishsd  equipment  and  interfaces. 
[Ref.  13] 

SPLICE  NETWORK,  Provides  the  connectivity  between  geograph- 
ically distant  SPLICE  locations.  Government  furnished  data 
communications  lines  shall  connect  the  locations  through 
common  carrier  lines  and/or  through  a  Government-furnished 
network.   [ Ref.  13 ] 

THREAT.   See  section  II. A.  2. 

USER.  k  person  oc  organization  receiving  products  or 
services  produced  by  a  ADP  system  either  by  access  to  the 
system  or  by  other  mains. 

USER  ID.  Data  elament  input  to  identify  a  system  user  and 
to  label  processing  products  resulting  from  the  user- 
initiated  processing.   [Ref.  13] 

VULNERABILITY  See  section  II. A. 3. 
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APPENDIX  C 
DEFENSE  DATA  NETWORK 

This  Appendix  prDvides  a  short  summary  of  the  Defense 
Data  Network  (DDN) .  The  source  document  used  is  the  Defense 
Da^a  Network  Program  Plan  revised  May  1982  [ Ref .  38]. 

A.   GENERAL  DESCRIPTION 

The  DDN  will  be  an  integrated  packet-switching  data 
network  designed  to  satisfy  all  DOD  data  networks  require- 
ments projections  through  the  1990's.  The  DDN  will  take 
advantage  of  existing  networks,  notably  the  WWMCCS 
Intercomputer  Network  (rfIN)  and  the  Advanced  Research- 
Projects  Agency  Network  (ARPANET),  and  will  be  based 
primarily  on  ARPANET  technology.   Table  X  lists  the  standard 


TABLE  X 
Standard  DDN  Components 

Switching  node  hardware 
Switching  node  software 
Cryptographic  ievices 
Mill -T ACs 

Host  front-en!  devices 
Host  interface  devices 
Mult  iplexors 


ccmponents  to  be  used  in  the  DDN. 

There  will  be  171  switching  nodes  located  at  about  85 
widely  distributed  sites.  The  switching  node  is  a  Bolt 
Baranek   and   Newman    (B3N)     C/30,    a    microprogrammed 
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minicomputer  costing  about  $45,000  (including  TEMPEST/HEMP 
protection)  .  The  r/30  is  designed  for  unattended  opera- 
tions. All  switching  nodes  will  be  located  on  military 
facilities  and  secured  to  at  lsast  the  SECRET  level.  The 
network  will  have  a  principle  System  Monitoring  Center 
(SMC),  an  alternate  SMC,  regional  Monitoring  Centers  (MCs) 
in  Europe  and  the  Pacific,  and  MCs  for  each  separate 
community. 

The  DDN  provides  for  increased  survivability  in  several 
ways.  The  171  fixed  switching  nodes  and  9  fixed  MCs  will 
have  HEMP  protection  (EM  shielding,  line  isolation,  and 
surge  arresting  protection).  Sites  with  no  backup  power 
will  be  provided  in  interrupt! ble  power  supplies  (UPS). 
There  will  be  five  preposit ionei  mobile  reconstruction  nodes 
equipped  with  MC  capability.  A  dynamically  adaptive  routing 
algorithm  will  automatically  r:ite  traffic  around  congested, 
damaged,  or  destroyed  switches  and  trunks.  Additionally,  a 
dense  trunk  in g  grid  will  provide  redundancy  at  all  possible 
points  in  the  network.. 

There  will  be  at  Least  99£  availability  between  any  pair 
of  singie-h cmed  users.  Critical  subscribers  will  be  dual- 
homed  (a  single  aooess  line  to  t  wo  switching  nodes), 
providing  at  least  99.5%  availability.  Dual  access  lines  to 
a  single  node  can  also  be  usei. 

Precedence  levels  can  be  assigned  by  originating  hosts 
and  terminals,  and  will  be  used  in  the  allocation  of  network 
resources.  Switching  nodes  provide  for  four  levels  of 
precedence,  with  preemption  of  lower  precedence  communica- 
tions. Category  I  (FLASH  and  FL  ASH-OVERRIDE)  communications 
will  be  processed  in  non-blocting  mode  exclusive  of  all 
other  traffic  modes  and  volumes. 

Communications  errors  will  be  minimized  by  the  use  of 
error  detection  and  correction  mechanisms.  A  Cyclical 
Redundancy  Check  <C RCt    of  15  bits  is   associated  with  host 
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messages  on  the  access  lines  aa3  packets  on  trunks.  A  32 
bit  CRC  is  used  with  S IP-compatible  hosts.  Additionally,  16 
bit  checksums  are  provided  on  aa  end-to-end  basis  within  the 
switch  subnetwork  and  on  a  user-to-user  basis  via  the 
Transmission  Control  Protocol  (TCP).  Error  detection  and 
correction  hardware  is  used  in  the  switches  for  protecting 
against  memory  failures  and  for  checksumming  of  critical 
data    structures    and    portions   of    code. 

B.       SPECIFIC   DDN    HARD* ARE/SOFTW&RE 

1-  Switching   Nods 

The  BBN  C/3 0  packet  switching  processor  is  a  multi- 
board,  microprograimed  miniconputer ,  with  61k  words  of 
random  access  memory  (RAM) ,  which  supports  a  full  range  of 
synchronous  and  asynchronous  1/3  interfaces.  The  C/30  soft- 
ware is  the  ARPANET  Interface  Message  Processor  (IMP) 
program  which  can  be  loaded  locally  (from  a  cassette)  or 
downline      loaded   fron      a      MC.  The   software      provides      the 

following    functional   c apabilitiss: 

•  Store   and  forward   traffic   processing. 

•  Hos-  access  and  end-to-end  traffic  processing  (with  a 
variety    of    host    access    protocols,    see    p.     33    of    Eef.    38). 

•  Dynamic,  adaptive,  distributed  routing  which  measures 
actual  packet  delays  and  routes  individual  packets  along 
the   least  delay    pith. 

•  Monitoring   and  control   services. 

2-  Internet   Private  Line   Interface 

The  Internet  Private  Line  Interface  (IPLI)  is  a 
security  device,  currently  under  development  as  part  of  the 
Gray  Tree  program,  which  will  be  used  for  end-to-end  encryp- 
tion.        It    is    composed    of    three      functional    units:         a   KG   84 
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cryptographic  device  and  two  MC58000  based  packet  processors 
(one  on  each  side  of  the  Kj  3U).  Figure  C.  1  shows  the 
placement  of  the  IPLI  with  each  host  for  snd-to-end  encryp- 
tion on  the  DDN.  The  software  in  each  processor  will  be 
based  on  the  CMOS  operating  system,  with  the  basic  functions 
necessary  for  the  DDD  standard  internet  environment  and 
monitoring  and  centre!  functions.  The  protocol  interfaces 
conform  to  the  DOD  Standard  Internet  Protocol  (IP).  Since 
the  packet  processing  occurs  at  the  lower  level  of  the  IP, 
the  TCP  and  other  protocols  which  exist  above  the  IP  can  be 
supported. 

Exclusive  of  the  KG  84 ,  the  estimated  unit  cost  for 
production  IPLIs  (after  FY84)  in  lots  of  100  or  more  is 
$15,000. 

3.   Minl^TAC 

A  mini-TAC  is  a  terminal  access  device  that  allows  a 
cluster  of  up  to  1 6  synchronous  and  asynchronous  terminals 
access   to      the    network.  It   is      logically    equivalent      to   a 

network  host  and  will  use  the  sane  host-host  protocols.  The 
ARPANET- bas ed  mini-TA3  software  allows  a  terminal  to  connect 
to  hosts  on  the  network.  The  aini-TAC  software  multiplexes 
all  the  terminal-hose  connections  over  a  single  link  between 
it      and     the      switching    node.  Since      Miai-TACs      will      not 

initially  provide  dial-up  access,  access  will  be  over  hard- 
wired lines  and  controlled  by  physical  access  control 
measures. 

The  mini-TAC  will  be  constructed  around  a  Motorola 
MC68000  microprocessor  with  nemory,  15  synchronous  or 
asynchronous  terminal  ports,  and  multiple  network  interface 
ports  (to  allow  d ji 1-homin g) .  The  mini-TAC  will  meet 
TEMPEST    and   HEMP  requirements.  Mini-TACs    will    communicate 

with  other  network  hosts  using  DOD  standard  TCP  and  IP. 
Terminal    level    support    is    provided    via   the    Telnet    protocol. 
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Figure   C- 1         End-to-end   Encryption. 
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The  mini-TAC  will  be  assigned  for  unattended  opera- 
tions. Control  functions  and  hardware  ani  software  fault 
diagnosis  can  be  dons  remotely  from  a  Monitoring  Center. 
Repair  will  be  by  board  swapping.  In  quantities  of  100,  the 
production  cost  per  unit  is  estimated  at  $7500  plus  $250  per 
port. 

C.   SECURITY  FEATDRES 

1  •   Link  Encryption 

The  K3  84  crypto  devise  will  be  used  on  all  back 
bone  trunks,  on  all  access  lines  to  classified  hosts,  and  on 
access  lines  to  sites  that  act  as  MCs  for  the  unclassified 
community.  Because  all  hosts  will  use  the  IPLI  described 
above,  communications  on  the  trunks  will  be  "super 
encrypted."  The  link  encryption  will  conceal  traffic 
patterns  and  monitoring  reports,  which  might  yield  traffic 
analysis  information.  It  also  protects  MC-switch  control 
traffic,  which  is  important  since  this  traffic  includes 
downline  loading  of  sensitive  switch  software. 

2-   Security  Level  Separation. 

Separation  of  subscribers  operating  at  different 
system  high  levels  is  provided  by  the  use  of  IPLIs  (at  least 
one  IPLI  key  for  each  different  system  high  level) ,  creating 
at  least  one  logical  subnet  for  each  security  level.  Since 
IP  and  subnet  headers  must  bs  in  the  clear  for  packet 
processing  within  the  switch,  all  switches  are  TEMPEST 
enclosed  and  in  military  facilities  secured  to  at  least  the 
SECRET  level.  Establishment  of  logical  subnets  will  guar- 
antee against  delivery  of  communications  to  any  subscriber 
outside  the  subnet.  This  guarantee  against  misdelivery  will 
be  used  to  protect  statistical  reports  from  being  delivered 
to  any  hosts  other  than  an  MC.   Each  MC  and  the  fake  host  in 
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each  switch  that  comnu nicates  with  the  MC  will  be  members  of 
the  logical  subnet.  additionally,  only  the  SMC  can  retrieve 
and  accumulate  traffic  statistics. 

3«   Separation  of  Communities  of  Interest 

Communities  of  interest  are  subscriber  groups  which 
present  an  acceptable  level  de  risk  to  each  other  and 
reguire  a  high  level  of  interoperability.  Separation  of 
communities  of  interest  is  accomplished  through  the  creation 
of  logical  subnets  oy  cryptographic  means,  by  software 
control,  or  both.  For  unclassified  subscribers,  the 
switches  provide  the  ability  to  define  logical  subnets  which 
restrict  traffic  to  flow  only  among  the  members  cf  that 
logical  subnet.  The  number  of  subnets  provided  by  the 
switches  is  currently  limited  to  16,  but  can  be  increased  to 
32  or  64. 

Classified  user  communities  will  be  separated  by 
IPLI  subnets  (like-keyed  IPLIs) .  Current  policy  limits  IPLI 
separated  communities  of  interest  to  128  subscribers. 

y«   Individual  Access  Control 

Access  control  to  subscriber  facilities  is  the 
responsibility  of  the  subscribers  themselves.  The  network 
will  assure  that  access  of  one  subscriber  to  another  is 
controlled  with  respect  to  authorized  security  level  and 
community  of  interest,  but  will  not  verify  that  an  iniivi- 
dual  user  (person  or  process)  has  valid  access  rights  to 
that  subscriber. 

5-   Personnel  Clearances  and  Ke_ys 

All  personnel  with  ^.zcbss  to  switches  must  be 
cleared  to  the  SECRET  level  3ue  to  the  traffic  analysis 
potential.  This  clearance  level  also  applies  to  all 
personnel  at  the  MCs.    Personnel  manning  an  MC  for  a  secure 
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subnet  must  be  cleared  to  ths  Level  of  the  subnet  subscri- 
bers. Crypto  technicians  wilL  be  required  for  keying  the 
IPLIs  for  each  community  and  for  link  K3s.  The  keying 
material  for  each  IPLI  community  is  available  only  at  the 
IPLI  sites.  The  keying  naterial  for  the  link  KGs  is  avail- 
able on  a  pairwise  basis  at  the  switch  sites  based  on  switch 
connecti  vit  y. 
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